Well, I don't think I grasp that idea yet. As Zest is now, during bootstrap, the user define the Assembly, which is used to create the Model, from which the Instances are created and bound. But I somehow have a gut feeling that your "Model" is not the same concept as the Zest "Model".
It was decided a long time ago, that allowing types to morph in runtime is an anti-pattern and practically creates more problems than it solves. Not sure if you are suggesting that you are actually supporting that, i.e. AnimalComposite something = ....; typeManager.addType( something, Prey.class ); In the primordial version of Qi4j, that was possible, but really makes the brain tired and troubleshooting a hair-pulling contest. On Thu, Jul 2, 2015 at 11:55 AM, Stanislav Muhametsin < [email protected]> wrote: > On 2.7.2015 9:39, Niclas Hedhman wrote: > >> All these "advanced usecases" points towards what Kent is hinting; A major >> design overhaul. >> > > A thought for major design overhaul: I can recommend based on experience > that it would be a good idea to have Assembling/Model/Instance layers in > Zest as well. > Basically for each interface or class that you have, decide which of those > layers it should go (or in "Common" layer, if it is used in more than one > layer). > This will help a lot also with coming up with mechanisms to support > "Composite Type as Plug-In" -idea. > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
