[nem-en] Multiple project solutions

[Kamil Skalski]

2007/1/10, vc <vc at rsdn.ru>:
>
> > > If we admit generation of top level constructions in expression macros
> > it
> > > will result in undefined behavior (in design-time). And behavior in
> > > design-time and compile-time will be differing.
> > >
> >
> > It is user's choice to get into such situation.
>
> It's "user choice" will turn to our pain. :)
>

I can see that you can now see the world from our perspective
(especially when we compare to bug
http://nemerle.org/bugs/view.php?id=776)

We can invent a method to minimize such effect. Note that those macros
by nature do something only if compiler compiles method with them, so
it is natural that code using the generated class is also local to
this method / class. And in order to avoid duplicated classes
generation user need to check for compiler mode / existing generated
stuff anyways. So my guess is that in practice it should not cause
much problems and if it does user will be able to workaround them (by
checking if code he wants to generate exists already).

The essence of this feature is "on demand" / "lazy" execution - when I
need some class/field, it will be created, otherwise not.
In the logging example, each class needs to have a logger object,
which listens to the logs, but if I don't have any log statements,
then I don't need the object - so my macro generates the object on
demand.

With the Units example - I agree, I also see declaration based
generation as better... But for "private" helper fields/methods or
other stuff...

-- 
Kamil Skalski
http://nazgul.omega.pl