[nem-en] Multiple project solutions

[Kamil Skalski]

BTW. I don't quite understand why do you accept top level "attribute"
macros generating code, but don't accept expression level ones. Those
two uses cause similar problems:
when VS must re-parse the project, then generated classes may be
cleared (and then engine would have to somehow know which macros
execute again) or if they are not cleared, then they might cause
duplication errors during second execution

As for the places, which depend on code generated by expression level
macros, I wouldn't care much about it - even now we don't (and we
can't) guarantee order of compiling types / methods, so such code can
break anyways. So I think that the valid uses of expression level code
generation are of two kinds:
- macros are generating classes / methods / fields, which are used
just after their execution in the same methods, where they were
invoked
- macros are generating code as a side effect only (so this code is
not used anywhere in the project)

The second one can cause similar problems as we discussed for using
macros - if you cannot ensure that all methods were processed, the
only way to make generated code visible is to generate compiled
binary... I guess this is a rare case, but it can happen and I think
we can accept such workings - usually if such situation exists then it
is for "generated stuff" assembly, which is dedicated as holder of
automatically generated code and user will try to keep it compiled
most of the time. For me it is natural, that if I do heavy code
generation, then I will always "pre-generate" the target library when
I need and then use it in other projects.

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. :)
>
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


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