Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Subject: Re: [Discuss] Object lifecycles...
To: dev@zest.apache.org
References: 
 <CADmm+KfB2Bb9iGrpBTB0zyKLXeh3J9e1A7SM1ykDLoYyNU0wNg@mail.gmail.com>
 <56604EFA.8010208@zest.mail.kapsi.fi>
From: =?UTF-8?Q?Kent_S=c3=b8lvsten?= <kent.soelvsten@gmail.com>
Message-ID: <56606464.6050905@gmail.com>
Date: Thu, 3 Dec 2015 16:48:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56604EFA.8010208@zest.mail.kapsi.fi>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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
>