[antlr-interest] C# TARGET ANNOUNCEMENTS

[Micheal J]

Johannes,

> > Thanks. The bug that required C# v2 to fix. I might have to 
> backport 
> > that specific fix. What was the fix for?
> 
> I've replaced the reference to csharpTypeInitMap with 
> "default(<typeName>)". If you "backport" this change, then 
> you will only destroy C# 1.0 compatibility for CSharp - which 
> is exactly that what I don't want.

Understood. The bug was due to the type initialization system implemented in
ANTLR. Nothing to backport then.

> > How is this achieved?. Using any value type without needing 
> a template 
> > change I mean...
> > 
> > The use of Nullables to solve (the obvious solution) 
> doesn't require a 
> > new target AFAICT. Just C# v2+.
> 
> The "default(type)" syntax initializes an object depending on 
> type. For value types, their default constructor is invoked. 
> For reference types, they are set to null. Nullables still 
> leave a hole, which my solution doesn't.

Cool. This is the cleanest solution for C# v2+ (once C# v1.x compatibility
is no longer important). Didn't think the default ctor was invoked. Thought
default() just initialized value-types to 0 and ref-types to null.

Our working assumption was C# v1.x compatibility in same target so we kept
the ANTLR type init system. We investigated nullables as a means to support
both C# v1.x and v2.x+ in the same target (using preprocessor directives to
support differences in syntax) but didn't do any more in available time.

> > YAGNI?. We can agree to differ about Token's utility. It's 
> easy enough 
> > to retain it locally here in any case.
> 
> I assume that you like Token as the abstract class which 
> defines some standard behaviour which is likely needed by 
> classes derived from it. In that role it failed miserably, as 
> either no behaviour was defined or the defined behaviour was 
> useless anyway for the deriving classes. IMO, the role is 
> filled by CommonToken anyway (is that correct, Ter?), and 
> whatever code has been removed from the Token class could be 
> replaced easily if the need actually arises.

The standard java runtime has no equivalent to the old Token class in C#.
CommonToken and ClassicToken implement IToken but are otherwise unrelated
(nor should they be). Token is useful for injecting common behaviour when in
custom variants of the runtime.

> >> Well, it could be that I'm using Linux and Nant 0.86 Beta, 
> but I get:
> > 
> > Most likely is. We didn't have time to do Mono build testing for 
> > obvious reasons...
> 
> Did you test it on your Windows machine? I'm sure that my 
> first test to use that build script was on Windows and it has 
> failed then, too.

Yes. It was used to build everything incl. the runtime distros for .NET v1.x
and 2.x.

> > Prebuild has bugs in it's Nant build file generation and 
> vs2005/vs2008 
> > project file generation iirc. Related to resource files I think but 
> > can't remember the specifics at the moment, sorry.
> 
> I will look into that. Maybe I'll fix the Nant build instead, 
> although having a functional Prebuild setup would help for 
> the VS project files.

Might be worth checking if Prebuild be moulded to generate Nant files that
can build docs, the distro archives etc in addition to building the
assemblies...

Micheal

-----------------------
The best way to contact me is via the list/forum. My time is very limited.