[antlr-interest] C# Target Poll

[Johannes Luber]

> Adding external dependencies is best avoided, since it adds to the
> maintenance problem, irritates new users who have to locate and install extra
> libraries, and causes problems for organizations who are trying to apply
> disciplined software practices and have to validate any externally supplied code.

This a good argument against changing.
> 
> Two approaches which work (after a fashion) are:  1.)  "steal" parts of
> the library and incorporate them into the runtime--that way, you have taken
> direct control over bug fixes

That may be a good solution, as one can keep the overall size down.

--and 2.)  fork the C# runtime into a
> C5-dependent and standard library versions.  Then adoption of C5 is a user option,
> not something imposed on them.

It should be possible by using the preprocessor alone. If only interfaces instead implementations are used one could even extract the allocations into a factory, thus allowing people to provide their own implementations. One problem would be, how to tell the runtime what factory to use. This should be ideally an invisible option for those not interested.
> 
> "The road to hell is paved with good intentions" very much applies--you
> may want to resist temptation.

At least thinking things through before making the final decision.

Johannes

> 
> --Loring
> 
> 
> ----- Original Message ----
> > From: Johannes Luber <JALuber at gmx.de>
> > To: antlr-interest at antlr.org
> > Sent: Friday, May 16, 2008 4:27:29 PM
> > Subject: [antlr-interest] C# Target Poll
> > 
> > Hi!
> > 
> > While thinking about future improvements, I came across over the switch
> of the 
> > used collections from the .NET versions to the one supplied by C5 
> > . The C5 library has more functionality and more 
> > types of collections than the .NET. Instead replicating text from the
> PDF please 
> > read at least the introduction yourself: 
> > 
> > 
> > My motivation to consider C5 is simply that I prefer to use
> state-of-the-art 
> > tools, and to a certain extent .NET falls short. I have used it in a few
> > projects so far and will use it again. It is easy to use. I had no
> problems 
> > besides non-binary-serializing of a dictionary, which was caused by .NET
> bugs, 
> > so I wouldn't hold that against C5. Also, serializing seems to be an
> unusual 
> > need for compilers anyway and can be circumvented by own designs anyway,
> as it 
> > probably would have been anyway. Please correct if I'm wrong and C5
> would 
> > prevent doing from something what you can do now.
> > 
> > Still, I can't simply switch the engines as I'd enforce the same change
> for all 
> > C# target users. As I can see, the use of C5 has the following
> disadvantages:
> > 
> > -The inclusion of another assembly, thus increasing the application size
> > -C5 may be fast, but the .NET classes are speedier as they sacrifice
> some of the 
> > extended functionality. How much exactly, I don't know, but if you care
> about 
> > nano-seconds, then C5 might be the wrong choice. Compiler builders care
> about 
> > the speed of their software after all.
> > 
> > Not problematic is:
> > 
> > -C5 can be used like ANTLR in (non)commercial projects as it uses a
> BSD-like 
> > license.
> > -It can be integrated with .NET classes as it is based on interface
> programming.
> > 
> > In case, I have overlooked important points, please shout them. I
> haven't done 
> > any work to switch to C5 yet, so voting down my suggestion won't waste
> any 
> > effort from my side.
> > 
> > Johannes
> > -- 
> > Psssst! Schon vom neuen GMX MultiMessenger gehört?
> > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
> 
> 
> 
>       

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger