I am not at the computer atm, but if you are talking about getting rid of dereference(), then I think you are out of luck, although it may look like working in simple tests.
Why? Qi4j Runtime constructs an invocation stack for each method in a composite. There is a Proxy at the top which represents the Composite, and upon invocation it will locate *a free* stack for that method, and if none exist create a new one. When a stack is located it sets the stack's internal state to point to This composite instance. This means that the reference to @This in a fragment is only valid within the execution of a Fragment method. The reason for this is to save memory. If we had one invocation stack per composite instance method, well.. I think you get the idea... and although there is a solution for this, we also need to keep it (method invocations) fast, so that a single reference is set to @This, instead of locating and injecting them one by one in each Fragment. So, the 'dereference' must happen before the call leaves the confines of the Composite. To locate all places where this could potentially happen is risky, and will take a perf hit in many cases. We opted for it to be a programmer's issue, and later with the help from the IDE which I think can quite easily make it an error to pass these references in method calls with the dereference(). Did that answer your question? -- Niclas On Aug 29, 2009 1:43 AM, "philippe van dyck" <[email protected]> wrote: Correction... public void set(T aNewValue) { if (isImmutable()) { throw new IllegalStateException("Property [" + q... value = aNewValue; // Change property if (Proxy.isProxyClass(aNewValue.getClass())) { InvocationHandler handler = getI... entityState .setProperty(propertyInfo.qualifiedName(), (T) ((ProxyReferenceInvocationHandler) handler) .proxy()); return; } } entityState.setProperty(propertyInfo.qualifiedName(), aNewValue); } Le 28 août 2009 à 15:30, philippe van dyck a écrit : > Rickard, > > IMHO, this kind od rare occasions will have a deep impact on the Qi4j learning curv... _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
