Re: Generating C# from Java (Was: fit, nfit, et al?)

----- Original Message ----- 
From: "Jim Little" <[email protected]>
To: "[email protected]" <[email protected]>; "'FIT
Developers'" <[email protected]>
Sent: Friday, August 08, 2003 2:59 AM
Subject: RE: [Fit-dev] Generating C# from Java (Was: fit, nfit, et al?)


> From: Daniel Gackle
> > I agree with you that this is NOT the simplest thing that could
> > possibly work.  Java and C# may be closer than any other two
> > languages I've worked with, but this would still be a big job.
>
> One -- I'm _not_ interested in writing a general-purpose Java -> C#
> translator.
> Two -- Trying to keep multiple revisions of the same codebase in sync is
> a complicated pain in the ass.
>
> Not to mention that having to keep multiple revisions in sync is a major
> disincentive to making changes.
>
> So I'm not so sure that a generator isn't the simplest thing.  At the
> moment, my thoughts are running along the lines of a simplistic parser /
> regex thingie that also has Javadoc-ish comments to help direct the
> process.
>
> I haven't talked to Ward about this yet so I don't know what he thinks.
> When we first started the port, we looked at a regex-style approach but
> postponed it in favor of getting a first release out, and we never got
> back to it.
>
> One thing's sure: this is future stuff.  Right now, I just want to get
> the .NET version back up to par.

One thing to remember here is that there are more ports than C#!
I spent a couple of weeks bringing the Python port up to spec,
and I ran into a number of problems that simply wouldn't turn up
in the C# port. Among them:

1. You cannot have two methods in a class with the same name,
regardless of the signatures. This affects everything, including
naming in the HTML. Frex, there is a fixture somewhere that
has right, wrong, ignored and execption as names. That conflicts
with the same names in the Fixture class.

2. You can't have two different constructors, regardless of names.

3. It needs a completely different approach to acquiring type
information for the TypeAdapter. The original approach had
major problems (not even mentioning the fact that Guido
blew it out of the water in 2.2.3 and later,) and I'm not at
all sure that the new approach doesn't need some tweaking
before it's ready for prime time. In particular, I don't seem to
have dealt with inheritance.

4. Depending on Java packages doesn't work for everyone.
Frex - Prior to 2.3, Python's date handling is basically a thin
layer over the C++ library, and in 2.3 the new date package
has very little resemblance to Java.

Doing an automatic translation is an intriguing possibility, but
I'd suggest doing it in two stages:

1. A conversion from Java to some kind of a parse tree
2. A language specific generator.

Otherwise, it's basically wasted effort from the Python
(and I suspect the Perl, Ruby, etc...) point of view.

John Roth
>
> Jim
>