http://xent.ics.uci.edu/FoRK-archive/feb98/0129.html
On Wed, 11 Feb 1998, I Find Karma wrote:
> So then what are the main reason to use objects? Oh, you answer that next.
>
> > Heck, I'm into objects mainly for decomposition and encapsulation.
> > I can live without inheritance, certainly without complex rules for
> > multiple inheritance.
>
> Decomposition and encapsulation, with inheritance optional.
> There's your answer as to why objects are good, Dave Crook.
Yeah, wonderful stuff. But what's encapsulation?
Is it behaviour+state all wrapped up together in a singular
identifiable package? What if I had state in one package, behaviour in
another, but linked the two "somehow"?
In the past of course, this was a language implementation issue.
Smalltalk(80?) represented objects by placing their state along side a
pointer to their implementation - for obvious reasons. Java
serialization supports referencing classloadable implementation by
embedding an URL to a class in the stream. Same thing.
So what exactly is the link between the state vector (which also has the
identity, don't forget), and the behaviour? Why, it's a meta
relationship! It's a statement of "If you want to interpret this thing,
use this!".
Heck, you don't even need to have an explicit reference in your state
vector to any behaviour. That can be decided at runtime, based on the
required services of the user/client. OpenDoc for non-humans, if you
will (long time subscribers will remember a post I made to Joe about
this, perhaps when this was still FoRR).
I don't think anybody would call this last case "encapsulation", yet it
looks pretty useful to me. But perhaps reifying the meta relationship in
a trader is "good enough"? Not sure. But what's clear is that what was
once a language implenetation issue, is now right in our faces.
BTW, I hope everybody's read Frank Manola's Towards a Web Object Model"
by now. Wonderful work, Frank. Should be required reading for dist-obj
membership!
http://www.objs.com/OSA/wom.htm
> But can't you have decomposition without having objects? Doesn't the
> "philosophy" of objects transcend whatever meme is currently hot, as
> Dave Crook suggested?
>
> My attitude is, yes, object philosophy != existing object tools. We can
> learn from objects without using them as a hammer wherever there are
> nails.
Yep, I'm with you Adam.
> How in the world are we going to add complexity AND reduce errors
> simultaneously in the next generation of software?
Details, details. 8-( Anybody looking for a Ph.D topic?
> > Sure, we could probably start all over and build a world of tomorrow
> > without trying to leverage what we already know about the less
> > ambitious, static, local, non-concurrent "objects" of today. But I
> > fear we'll be relearning a lot of those lessons if we build on,
> > e.g. web/cgi, without recognizing the legacy (?! what a strange word
> > here!) of "classic" OO.
>
> Web/CGI is not an enemy of OO. The underlying *philosophy* of the Web
> is that of objects being passed around a network.
And we all thought HTTP was stateless for no good reason! Silly us.
Still, it would be nice to be able to give identity to those mobile
documents after they've moved, but that'll come, right? Object groups
anyone?
> Of course, over there I sometimes see threads debating whether documents
> and objects are the same, so we see similar themes crop up in both lists
> sometimes.
Maybe "debating" isn't the right word. Recently at least, I haven't seen
anybody suggest that they weren't the same thing - in theory. It remains
to be seen if the strongheaded object types will understand what the
Web's doing before it's too late.
MB
-- Mark Baker, Ottawa Ontario CANADA. Java, CORBA, XML, Beans http://www.iosphere.net/~markb distobj@acm.org ICQ:5100069Will distribute business objects for food.