--- Marc Portier <[EMAIL PROTECTED]> wrote:
> Tim,
>
> your postings on the list urged me to get some deeper into this
> specially on the 'cyclic' stress on the building process brought
> in by the class/new stuff and specially how that clashes with the
> 'private final' mantra I've been chanting :-)
>
> obvious observation is that the cyclic stuff will prevent us from doing
> any 'final' declaration on the pointer from 'new' to it's 'class'...
I found a solution that allows a true 'final' declaration!
Problem:
If we create an instance of A before B exists, then when B is created
it is too late to set the reference to B in the 'final' member of A.
Of course there is no problem setting the reference to A in the 'final'
member variable of B, because A already exists. The cyclic problem is
that there is no order in which to create A and B such that each can
hold a 'final' reference to the other.
Solution:
If we could split the timing of the creation of the object A or B from
the initialization of the 'final' member variables the cyclic problem
would vanish. This can be done by initializing the 'final' member
variable in a constructor. Some sample code may make this clearer:
class Sample {
private final Sample child;
public Sample(Builder builder, Sample child, String otherConfigData) {
if (child != null) {
this.child = child;
} else {
this.child = builder.getChild(this, "someChildId");
}
// Use otherConfigData to finish setting up object
}
}
class Builder {
public Sample build() {
// Because the value 'null' is passed in place of an
// actual child reference, we know that the constructor
// for this object will call this builder's getChild
// method. We will continue building from there.
Sample sample = new Sample(this, null, "Some config data");
}
public Sample getChild(Sample parent, String childId) {
// The parent object (think object A in the example)
// has been created by this point, but its constructor
// will not finish processing until this method returns
// the requested child reference.
// If we now happen to build object B, from the example,
// we have a reference to object A ready to pass as the
// child object parameter to the constructor that builds
// object B. After object B is built, this method can
// use a return statement to pass the reference to object
// B back to the constructor of the parent that requested
// it (object A). Problem solved, compiler happy :)
}
}
Application of this solution to the building of cyclic bindings and
definitions is trivial and is left as an exercise for the reader ;)
WDYT?
--Tim Larson
<PS> Marc, I'm still mentally working through your responses and will
eventually give a point-by-point reply. I'm not sure what my
timetable looks like right now, though. As a quick note, neither
"class" nor "new" currently wrap any namespacing around the widget
definitions that are retrieved from the class via "new". That is:
<wd:class id="asdf">
<wd:widget id="qwerty"/>
</wd:class>
<wd:new id="asdf">
is functionally equivalent to:
<wd:widget id="qwerty"/>
and *not* to:
<wd:some-wrapper-widget-or-element id="asdf">
<wd:widget id="qwerty"/>
</wd:some-wrapper-widget-or-element>
(How) does this affect your proposals?
</PS>
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
