This thing came to my mind when writing previous mail about Assemblies,
Models, and Instances.
Is it true that Zest still has limitation/restriction not to support
generic composites (i.e. MyComposite<T, U> -interfaces as composite types)?
IMO you might want to remove that limitation.
I am not sure if that is possible, since generics in Java exist only at
compile-time (is this so with newest Java?).
But I am certain that many people are most likely to give up on Zest
when they encounter that limitation (I know it was a tough
slap-in-the-face for me, when I encountered it).
If you decide to remove this limitation, I could give some pointers as
to which pitfalls to avoid, and what to keep in mind, when dealing with
generic composite types.
I encountered a lot of trouble when I implemented generic composites in
Qi4CS, but the type system in CLR preserves generic argument information
at runtime (so, in Java terms, that List<String>.class will return
*false* when doing equality comparison with List<Int32>.class), so it
was possible to implement support for generic composite types.
In Zest, it might make code generation more complex, and it might make
the method intercepting code in Zest more complex, but I think it is
worth the hassle.
