Re: I want to make a C# library of some classes
- From: Chris F Clark <cfc@xxxxxxxxxxxxxxxxxxxx>
- Date: 23 Apr 2006 13:04:46 -0400
Lebesgue wrote (replying to me):
Now I hope I understood your problem.
The first thing that comes to my mind is that you should simply include and
compile the BaseParser with the generated library - seems too simple for me
and I suppose you've got reasons not to do it.
Yes, there are actually more (at least 1, but less than 5) classes
between the BaseParser and the ApplicationParser, plus auxillary
classes that are involved. The point is all this code (and it is a
fair amount) is application invariant and if they use multiple
ApplicationParsers in one program, we want the code to be shared.
If I understand correctly, you need a kind of "logical late binding"
here, so the second thing that comes into my mind is to let them
type myData(2).numberNouns++ and let the code generator add the cast
according to context the command is used in or try to infere the
type from the property name they used - don't know which one is
applicable in your case.
We would also like to avoid having the tool (application generator) do
anything to the copied code beside copy it. There are a couple of
reasons for that.
First, it makes certain our tool doesn't get tied to a version of the
language. If someone makes a new version or variation of C#, we don't
want to have to change our tool to support that new version. More
importantly, we don't want to risk our tool getting the rules of C#
wrong and hindering someone from doing something valid because of an
error on our part.
Second, we want users to be able to write code that interoperates with
our generated code (and looks like the code that we copy from) but not
have that code processed by our tool. For example, someone might
write another class that calls member functions in one of our
generated classes. We want all the "magic" stuff that makes our code
to be correct, also to apply to their code, at least when they are
interacting with our classes. The more subtle case of that, is when
they derive their class from one our generated classes. We want what
makes our class work to make their class work, and they will be
writing their class in "vanilla" C#, so our solution must depend on
vanilla C#.
To explain this point more, in the early 90's our generated code was
written "very carefully" as a series of "include" files that we
combined with some "very sophisticated" source code with some "very
interesting" macros. As a result, our code although object-oriented
would actually compile in C as well as C++. However, the code was not
obvious to anyone outside our company. It was effectively a magic
incantation. Around 95, we redid our entire library getting rid of
any attempt to support C and simplifying the C++ so that "mere
mortals" could understand it. Some parts of the code are sill
slightly "unusual" C++, just because we want to retain certain
historical things (e.g. the traditional yy prefix always associated
with "yacc" tools). However, the code is still readable because we
stick to a simple subset of C++ (e.g. no templates, no multiple
inheritance, no complicated macros) and have small easily composed
classes in the library. We are never going back.
The ideal is that someone can take the generated code plus the library
include it in their project and edit it just as if it were code they
had written. We have customers who do that. We are even trying to
make our tool handle the round-trip case, where the users have edited
the generated output and need to make a change to the grammar and have
the two changes get integrated "automatgically" with minimal user
intervention.
We want our C# to have the same feel. Mostly, we have been
successful. Moreover, most of the C++ features work identically in
the C# version, so our customers who are used to the C++ version just
have to learn C# and not C# plus a new version of Yacc++.
This does not mean the code is the same. In C++ we use pointer types
extensively, while in C# we use reference types, and that make
numerous small syntactic (and occassionally semantic) differences.
Still, the result is roughly what we want, the C# version "feels" like
C# code, not a port of a C++ library into C#, while still providing
most of the subtle advances we made in our C++ version over 15 years
of refining it. Moreover, it looks hopeful that we will make
refinements in the C# version that will improve the structure of our
C++ version also.
This library issue is one thing we don't have solved.
I'm going to try to put a better understanding of our library problem
in a separate posting.
-Chris
.
- References:
- I want to make a C# library of some classes
- From: Chris F Clark
- Re: I want to make a C# library of some classes
- From: Lebesgue
- Re: I want to make a C# library of some classes
- From: Chris F Clark
- Re: I want to make a C# library of some classes
- From: Lebesgue
- I want to make a C# library of some classes
- Prev by Date: Re: Interesting C# puzzle
- Next by Date: Re: Dragging the mouse over a control
- Previous by thread: Re: I want to make a C# library of some classes
- Next by thread: How to resume an SSL-Session with SSLStream
- Index(es):
Relevant Pages
|
