interesting.... My previous P.O.V was that we should support the equivalent of [Prototype] .... for mixins .
Do you have some example use-cases from Qi4CS explaining the usage of [Initialize], or lifecycle methods on other fragment types? /Kent Den 03-12-2015 kl. 15:17 skrev Stanislav Muhametsin: > On 3.12.2015 9:38, Niclas Hedhman wrote: >> Gang, >> >> 1. Should Initializable.initalize() be invoked on prototypeFor()? >> >> At the moment, when prototypeFor() (and prototype() I guess) is >> called on >> TransientBuilder (probably ValueBuilder as well), the mixin's >> initialize() >> will be called. >> That means that the Composite is not really available (predictably) >> to the >> Mixin at this point. > > In Qi4CS, I have [Initialize] and [Prototype] attributes (@Initialize > and @Prototype annotations in Java). > Methods on fragments marked with these attributes will be invoked by > Qi4CS runtime in the following logic: > 1. Methods marked with [Initialize] will be invoked the first time > fragment is created (be it during prototype stage, or composite > creation), right after its constructor finishes executing. > 2. Methods marked with [Prototype] will be invoked when the > CompositeBuilder actually creates composite instance (prototype stage > ends), during its NewInstance() method. > > Naming is maybe not optimal, but I think you get the general idea. > The concept on not having interfaces and instead using attributes > (annotations) stems from rather old e-mail from you, Niclas. > I see you have revisited this idea later in this mail. :) > >> >> 2. Do we have a solid object lifecycle story at all?? >> >> While writing this mail, I start to think that the object lifecycle >> model >> is severely flawed, and possibly not easily fixed here and there. >> >> I think we need to dig through the requirements from the ground up. I >> think >> that the Fragments and the Composite need to be separated. >> >> I also wonder if we can indeed utilize finalize(), to get pre/post >> semantics uniformly across all composite meta types... Does anyone >> have a >> very strong understanding of how finalize() works, and why it is said >> to be >> "bad" to use it in programs?? > > Java's 'finalize' and C#'s destructors are very tricky, because most > assumptions that are valid during normal program flow, are not valid > in finalizers/destructors. > For example, in C#, the destructors are always run from within > dedicated finalizer thread (I don't know if Java does that). > Additionally, the fields of object during finalization/destruction > might point to already finalized objects, which can and usually does > cause a lot of subtle bugs. > > Personally, I've taken the stance recommended by C# - only use > destructors if your object needs to free native resources when it is > no longer used. > >> >> What I would like to see is pairs of annotations with strong semantics, >> something like (maybe better names) >> >> @OnEntityCreation // called on EntityBuilder.newInstance() >> @OnEntityDeletion // called on UnitOfWork.remove() >> >> @OnCompositeConstruction // called when in-memory instance created >> @OnCompositeDestruction // called via finalize() or UnitOfWork >> teardown. >> >> @OnMixinCreation // Called after Mixin constructor call. >> @OnMixinDestruction // called via @OnCompositeDestruction >> >> I am not sure if we need to separate the prototype/prototypeFor creation >> from the instantiation of 'final' Mixin instance that goes into the >> Composite. >> >> And in the process "fix" the ServiceComposite story as well, i.e. >> >> @OnServiceActivation >> @OnServicePassivation >> >> And in the process get rid of the all the related interfaces; >> Initializable >> Lifecycle >> Activatable >> ServiceActivator >> >> and so on. >> >> Any thoughts? > > I think annotations are excellent idea, and they have worked for me in > Qi4CS very well. > One thing you need to be careful of, is in which order you invoke > them: base-class-first or bottommost-class-first in class inheritance > hierarchy. > IIRC Qi4CS invokes the attributed (annotated) methods with > base-class-first strategy. > If a single class contains multiple methods marked with same > attribute, the order is whichever way they are returned by reflection > (this is checked only once - during code generation, once code is > generated, the order will always be the same). > > One very good thing (which you pointed out in the old e-mail) is that > attributed (annotated) methods can have parameter injections, and if > these injected values are used *only* in the lifecycle stage indicated > by attribute (annotation), then you don't need to have these > injections in fields. > >> >> >> Cheers >
