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
