[antlr-interest] C# TARGET ANNOUNCEMENTS

Johannes Luber jaluber at gmx.de
Fri Apr 11 14:16:05 PDT 2008


Micheal J schrieb:
> Johannes,
> 
>> Well, the latest changeset is 4759, but looking over the logs 
>> in perforce I see that I didn't mention it there. I assumed 
>> that once the wiki page is updated, people will know it in 
>> general. Otherwise I don't see any file in the source 
>> distribution, which mentions changes.
> 
> 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.

>>> One can use any value type with the 'CSharp' target already AFAICT. 
>>> Does the new 'CSharp2' target remove the need to update the 
>> 'csharpTypeInitMap'
>>> default value map in the templates for unspecified value types?
>> Actually, I meant this, even if it didn't came correctly over.
> 
> 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.

Also it seems that I haven't been that clear why I've created a new 
target. I can't simply remove support for C# 1.0, as much as I'd prefer 
that. While I don't believe that someone is using ANTLR with C# 1.0, I 
can't stop supporting it instantly. So I've announced its end-of-life, 
which may take a year or more to come to full fruition.

In the meantime, I have to provide compatibility. There are two places 
to support: the templates and the runtime. The runtime is quite easy as 
one merely has to link to the appropriate assembly and as maintainer I 
can provide those, even if the sources will be split somewhat.

The templates are different. I can't include in templates C# 
2.0-specific stuff without ensuring that for C# 1.0 compilers the stuff 
isn't visibly. One possibility is to use preprocessor directives. The 
disadvantage is that people have to define the right symbol - something 
which doesn't seem right to me.

Another possibility is to tell somehow ANTLR via an option, that one is 
targeting a certain language version and let the templates check for 
this new attribute. But that would lead to two targets in one file and 
the doubling of code makes it more difficult to fix bugs. I've come to 
the conclusion that the simplest solution is to create a new template 
target and have done so.

> 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.

>> 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.

>> I suppose it doesn't matter because I will switch to Prebuild 
>> due to later reorgs in the code base. Then I can get easily 
>> uptodate project files.
> 
> 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.

Johannes


More information about the antlr-interest mailing list