Of course it is. But I'm still struggling with the different
intuitions about what kind of object system it is, and can be.
Sorry to be a pest about it.
Some of this conflict seems to be just attitudinal/terminological:
> We would like to see more use of XML to capture the thing itself,
> not just the interface to the program which manipulates the thing.
Right. This is the essence of Vertical Objects: Some objects treat
(non-opaque) descriptions of other objects as their data. And
recursively so.
(Thanks to Steve Nordquist for suggesting `vertical objects' as a
replacement for my awful term `reflective object multilevelism'!).
> For
> data in-core, the working set, this may be overkill, but as platform
> half-lives collaps, externalized data lasts longer and longer by
> comparison.
Right. Using a common format/language across levels is nice, but is
not essential and is rare in practice. I wasn't arguing one way or the
other about it.
> However, there are economic benefits to speaking of documents as the
> objects in the long-term. Behavior may change, but the data files often
> last longer. Data files also have multiple uses; viewed in different
> ways by different subsystems. Rather than fragmenting relevant detail
> amongst many leaf classes, there are maintainablity benefits to bringing
> all customer contacts to a customer record, for instance.
Right. As a general design rule, one would like to partition
descriptions of essentials vs incidentals (whatever that might mean in
a particular design context). This is seen for example in standard OO
Model-View-Controller (Subject/Observer) designs which separate
essential model properties in one object, and different ways of
displaying these properties in GUIs via other objects that can be
plugged in and out.
But: (back to...)
> We would like to see more use of XML to capture the thing itself,
> not just the interface to the program which manipulates the thing.
In the general case, `capturing the thing itself' requires behavior
description. Right? I remain clueless about how this is supposed to
work. Purely declarative approaches to behavior description are
challenging at best. (As far as I can tell, the remarks that Dennis
deChampeaux (mostly) and I wrote about this 6+ years ago --
http://gee.cs.oswego.edu/dl/oosdw3/ch5.html -- still basically hold.)
More concretely, suppose I want a description of:
A Water tank
A Car alarm system
A Web server
A Bank
A Telecom switch
...
How would I go about it in an XML/.../... -based object system?
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/