This is a rather intriguing, and I think you'd agree - uncommon in
traditional OO circles- way of looking at things.
In fact, I recall that you made similar
statements in CPJ (Concurrent Programming in Java), about 2/3
of the way through - I don't have the book here in Brazil for
an exact page reference. The discussion there dealt with looking at
objects as "more like machines" (active, with process&data) or
as "more like memory" (passive data, acted upon).
(BTW - I found it rather strange that such statements would come
buried into later chapters - I think that material could be better
put up front, with more beefing up.)
In both the book,
and the comments you've just posted, I felt myself willing to be
persuaded by this argumentation,
but still not entirely so - I'd like more clarification if possible.
For example, software objects - the kinds we normally discuss -
have hairy issues of identity. Because it is so easy to replicate
bits, you can copy objects effortlessly - often, far too effortlessly.
That leads to all the problems of object identity, equality,
depth of copying, etc.
When I use the term "machine", even "abstract machine", as in
a Turing machine, issues of copying and replication and identity
don't seem to crop up... or do they? "Machines" somehow seem
more solid, more concrete. But even as I write this, I'm not convincing
myself :-).
For another thing, just looking at them as English words,
"object" to me seems a very generalist word. I've often done
mental substitutions of the word "thing" when I see the word "object",
just to reinforce to myself the notion that an object, physical or
virtual, can be just about anything. In fact, I believe that it's
because the word "object" is coopted so strongly by the OO
camp, who in their hijacking created the rule (according to
Booch, at least), that a language must support inheritance to be
an OOPL, that then caused everyone to go out and start
questing for "components", just to have another general term
where inheritance was optional. In contrast to this generality
of words like object/thing/component/part,
"machine" seems a rather specific
word. Whereas anything might be an object, I have a harder
time saying that anything might be a machine...
So as I said, I'm open to considering the object==machine abstraction
notion, but would like to see a more complete discussion of this mapping
and why you believe it's so. Maybe in CPJ 2nd Ed?
Maybe here?
>2. How it can be that XML and other non-computationally-complete but
> useful languages somehow serve as alternatives to objects.
I don't think they do. I don't think even the most radical XML-proponents
would argue that descriptive languages are sufficient. (Is this
true? Would die-hard webheads argue this characterization?
Now that TBL is on FoRK, I can't resist openly asking him
to respond to that :-).
Bosak and followers all talk about the marriage of XML to Java, not
the replacement of one by the other.
To me, the value I see in XML is primarily as drop-in replacement
for IDL. As you note, Doug, description languages are nice. We've
been playing around with IDL for about a decade. Lots of object
folks, like Desmond D'Souza, clearly are finding that we're limited
with what we have. Non-extensible grammars only go so far. We're
hitting the same limits with IDL (or Java interfaces) that the web
is hitting with HTML. When we seek IDL++, over on the other
side of the fence they're seeking XML.
I don't think there's anything intrinsically better about XML than
starting with an OO-influenced spec langauge like IDL. But where
I think XML has it over IDL and derivatives is the opportunity for
sheer market penetration and dominance. I think: "Wouldn't it
be wonderful if we could really have a de facto standard for everyone
to specify their "buckets of bits" on the Great Network? CORBA
philosophy is based on everyone somehow specifying everything
in IDL. That just isn't going to happen. Not just because IDL
is limited in expressability. But more pragmatically - the number
of folks who will use CORBA IDL, or who will build CORBA objects,
will always be a drop in the bucket compared to the number
of real bit-artifacts (objects, documents, scripts, whatever) "out there".
So if XML takes a good stab at a usable, extensible spec language,
but one that has the potential to dominate the bits pumped out
by just about everyone,
why shouldn't we wholeheartedly adopt it into the "object" camp?
So we get what we need in terms of extensible spec language,
but are finally compatible to the mainstream
out there, rather than locked into our little corner?
I know I'd never convince OMG to drop their beloved IDL (not
that folks like Frank Manola aren't trying - or at least trying to make
them see that XML can be synergistic with IDL). But out here
in the "critical" object camp (i.e. where gospel doesn't have to
come from OMG), I propose that (a) IDL-like
spec languages have a legitimate-
in fact an essential - role in object systems. Surely Doug
you wouldn't ask for a justification of how and why
IDL and objects play together!
(b) If XML works
as an improved IDL, and a far more popular IDL, then here is
one way in which XML/objects matrimony should be pretty
clearcut, I think. The advantage? It takes the whole "web/object
integration" concept and actually does something concrete
about it, rather than just talking about it.
Now I know that lots of others are considering more ambitious
goals for XML/objects - some of them are on dist-obj
(e.g. Bill LaForge, Mark Baker, Joe Kiniry). I'm willing to hear
them out (stuff like serializing to XML, replacing beaninfo with XML,
etc.) but for the time being the one thing I'm comfortable with is this
drop-in IDL replacement notion.
Actually - the beaninfo one
might make a lot of sense. My logic here is:
(a) beaninfo classes are to pure-Java as Interface Repository (IR)
is to CORBA systems. I.e. a runtime queriable repository
of metadata about an object. In the case of IR, the stuff you
can pull out is effectively a runtime parseable form of IDL for an
interface. In
the case of beaninfo, you can get all the visible properties and
events a bean supports. Pretty similar, huh?
(b) So, if XML is a replacement for IDL, and is already both machine
and human parseable, it makes a great candidate for an
internal representation of a CORBA IR, or , because of (a),
for beaninfo replacements.
beaninfo isn't being used today in the spirit of CORBA IR, since
beans today are predominantly local, and beaninfo's are used
in visual IDEs by developers wiring together their beans. But if
you were to streeeeetch those beans out on a wire,
and allow them to collaborate
at runtime, and wanted an IR like mechanism to go along with the
quasi-DII-like stub-loading features of things like RMI, well, presto!
It's made to order.
Does that help? Does it spark further debate ;-)?
Ron
-- Ron Resnick DiaLogos Incorporated Experts in Java and CORBA Technologies http://www.dialogosweb.com