On Sat, Apr 18, 2009 at 5:57 AM, Pelle Poluha <[email protected]> wrote:
> Done that and no difference. In fact, I have a Concern implemented in
> the same way which works:
>
> abstract class MessageConcern extends ConcernOf<MessageBehaviour>
> implements MessageBehaviour {
> String giveMeContent() {
> return 'concern for ' + next.giveMeContent()
> }
> }
The above also contains the 'next' member, so are you sure it works?
> abstract class MessageSideEffect extends ConcernOf<MessageBehaviour>
> implements MessageBehaviour {
> String giveMeContent() {
> println "sideeffect in action " + next
> return null
> }
> }
>
> It gives the result:
>
> sideeffect in action concern for speak
> concern for speak
> shout
Very strange. I presume that you have concern, sideeffect and mixin
doing output.
1. SideEffects should be executed last, and not first.
2. It looks like the sole 'next' has the method being called, because
if it was toString() something very elaborate would be output.
>> Can you break that down and point to exactly what is Null? And doesn
>> it work in Java?
>
> Sorry, can't make it happen again. But it was the subject property
> which was null:
>
> builder.stateFor(MessageState.class).subject().set "shout"
>
> The NPE didn't occur in the Java code.
I don't like intermittent code. :-(
>> We have not yet designed the mechanism, and the latest break-through
>> in persistence (seen in recent 6 part post) will touch on this again.
>
> Meaning migration still is a problem? How do you usually solve data
> migration after class changes?
Of course the system can not know refactorings that has occurred
without it being recorded somewhere. We have discussed to have plugins
to aid in that, but ultimately the programmer will need to provide
that information.
>> At persistence level, only Property, Association and ManyAssociation
>> are persisted. And for Property, the generic type must either be
>> serializable (we might even reconsider this), discrete or a
>> ValueComposite. For Associations, only the reference to the other
>> Entity is saved.
>
> What about ListAssocation and SetAssociation? Aren't those persisted?
> If only the references are persisted, does that mean that I have to
> wire the associated entities back together myself after retrieval? Is
> it done by searching for the reference id:s? I really would like to
> have an object graph back from the store.
List and Set associations are disappearing, and instead the
ManyAssociations will have toList() and toSet() methods.
The client programmer will not see that only the reference is saved,
and as a few other things, (Many)Associations are lazy-loaded, i.e. if
not traversed it won't be read from storage.
As for your Groovy experiments, you are pretty much on your own, we
won't be able to support you much, since we don't even know if it is
supposed to work at all. Further, we have Groovy support at Mixin
level, i.e. letting you easily implement Mixin code in Groovy. Perhaps
that is good enough. I guess similar support can be done for both
Concerns and SideEffects...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
