> Which is why I said conceptually, though maybe that's not the best word.
> From the programmer's naive point of view (i.e., what you might think if you
> don't look inside the .g file), someone calls new Foo(), at which point the
> constructor calls InitializeComponent, whose mission is to "go do all that
> stuff the xaml file says".
>
> It's not exactly the same as deserializing BXML in a constructor. In BXML,
> the root element is instantiated by BXMLSerializer, not the new operator.
>
> Yes. But does it have to be that way? I haven't looked at the
> BXMLSerializer code, so perhaps I'm being naive, but it seems like you could
> have a different entry point to the code, one that accepts the
> already-created root class as a parameter rather than creating one only after
> parsing the root element.
This is theoretically possible. An argument could be added to
BXMLSerializer#readObject(InputStream) that contains the root object to use,
rather than assuming that it is null. The constructor could then call:
readObject(getClass().getResourceAsStream("Foo.bxml"), this);
and ignore the return value (since it would be the same as this, and
constructors can't return anything anyway). Not a bad idea. Definitely
something to think about for a future release.
G
