RE: [xml-dev] Instances changing their type [was:Discover data patterns

["Michael Kay" <mike@saxonica.com>]

> > At a purely practical level, I'm constantly wishing I could 
> > dynamically change an ArrayList into a LinkedList without having to 
> > know about all the places that might hold a reference to it.
> 
> Could you please elaborate where this scenario has a 
> practical use (i.e., at run-time, or within a running 
> process/thread an ArrayList can be treated as a LinkedList) ?
> 
> In Java, ArrayList and LinkedList both implement the List 
> interface. I think, in a statically typed language like Java, 
> what you say might not be possible. I think, in Java to 
> implement your idea (i.e., swapping ArrayList and LinkedList 
> behaviour), we can design a new type (some form of list).
> 

You've got two different classes that implement the same interface, but they
have different performance trade-offs. But you have to decide which one to
use "in advance". If you want to change your mind later - for example if the
size grows to a certain level or if you notice a certain usage pattern, it
would be nice to switch over to a different implementation. But you can't do
that without changing the identity of the object, which means you need to
tell everyone who holds a reference to the object to update their reference.

Of course all problems in computing can be solved by adding a layer of
indirection. You can design a wrapper object that implements the interface
and delegates all the work to either an ArrayList or a LinkedList. This
wrapper object is the only object to know about the implementation object so
only one place has to change when the implementation changes. But it would
be nice if this were built into the language, not something you have to
program yourself. Apart from anything else, forwarding all the method
invocations is expensive.

Here's another example from the XML world: it's a quirk of the XSLT
specification that you don't necessarily know what serialization method you
are using until you write the first element node, and by that time you can
have written lots of comments and processing instructions (which the
serializer has to buffer, because their final output format depends on the
serialization method chosen). It's a reasonable design to have an HTML
serializer and an XML serializer that share the same interface to the rest
of the system; it would be nice to have a single serializer object that
initially is a wait-and-see serializer, and that later converts itself into
either an HTML serializer or an XML serializer without the client needing to
know anything about the change.

We came to this though from a data modelling perspective where the benefits
are even greater. If I've got three types, employee, pensioner, and
shareholder, and if a single person object can change its membership of
these three types over time, with a persistent identity that can survive a
change of type, then I have a much more accurate model of reality. If an
employee is a shareholder I only want to record his address in one place.
And I can use the common identity of the employee and the shareholder to
answer questions. Who is the author of this document? He's John Smith, who
was an employee until March last year but is now retired, we know his
current address because he still holds some shares in the company and
receives dividends.

I believe the motto used by Bill Kent (one of the IRIS designers) was
"identity should be orthogonal to type". It's one of those brilliant ideas
that for some reason never became mainstream and will probably be relaunched
by Microsoft as a sensational innovation in about 20 years' time.

Michael Kay
http://www.saxonica.com/