copy protocol and object ravioli

[Roger M. Burkhart]

In response to Glen's recent despair about OO-ness, whether an object
"copies itself" or is copied by an environment is a different, and deeper,
issue that using protocols for interface declaration.  As it happens,
there's already a protocol declaration for a standard form of zone-based
copy in defobj.h:

//
// Miscellaneous operations for mixing into other types.
//

//
// Copy -- copy all state defined as part of object
//
@deftype Copy
-               copy: aZone;
@end

(It's disguised with a deftype tag, but that's nothing but a #define
for @protocol used to feed some extraction scripts, which is in process
reverting to just plain @protocol, and usable as a protocol already.)

So, if you want to *declare* a copy message of this form, all you have to
do is adopt this protocol with your own protocol.  But a protocol does
nothing about supplying an implementation to go with the interface, such
as a default copy method as suggested by Barry.  For that, a true multiple
inheritance of implementation would still be handy, but isn't available
yet in ObjC.

The deeper issue of copy responsibility perhaps accounts for Glen's shaken
faith in OO-ness, and comes up whenever you have objects that are deeply
imbedded in some context or environment, or at least have many links or
relationships to other objects within such an environment.

The copy operation points out that you've got some decisions to make as to
what you call part of an object and something outside it, including which
links to break and re-establish when you copy the object, and perhaps what
links the environment itself needs to the new object.

Because Swarm is trying to represent everything within some modeled world,
you can't just create objects and toss them around willy nilly the way
some O-O programs seem to do, but instead must try to maintain them in
proper relationships to each other at all times, in much the same fashion
as databases with referential integrity try to do.

What all this means is that as a modeling construct (as opposed to a method
of programming), the pure "object-oriented" bias, of one object "containing"
or performing a set of actions that belong to it exclusively (like member
functions in C++ or Java), is not a very good match for many of the events
that occur in a complex world.  In a reasonably complex world, many
objects participate in relationships and multi-party interactions where
it's hard to say what lies inside one object vs. another object, vs. some
context surrounding them all.  In these cases, it can often be simpler
to surrender the responsibility for an operation to the containing
environment and let it sort out whatever needs to be done, in this case
using a different form of copy operation such as Scott Christley
suggested.  (Swarm conveniently supplies a swarm as one option for where
you might do this.)

I've heard this problem of overly object-centered bias referred to as the
"ravioli code" problem of object-oriented programming (with a bit of
tangled control like the old spaghetti code problem).  Many of the things
we care about, the interactions and relationships especially, lie in the
sauce that surrounds the objects, not in objects as self-contained
packets.

Swarm and Objective C are better equipped than most O-O languages to cope
with the ravioli code problem.  Even though method lookup is based on just
one "receiver" object, this is only an expedient of implementation.
Messages and selectors are first-class objects (at least C data objects)
in their own right, and Swarm uses this representation to invoke their
actions from its own schedule structures, with whatever effect they have
on all their arguments.

An Objective C message is in principle much closer to a Common Lisp "generic
function" (which makes explicit the equal weight of all arguments) than it
is to a simplistic single-object focus (in which the concept of a class is
conflated with the idea of a modular name-space package).

This is getting deep into the category of "dreaming of objective sheep"
that Glen worried would push out modeling issues, but the notion of an
object, the things actually referred to by our software objects, lies much
deeper than just our programming creations.  I agree with Glen that narrow
programming-variety objects often lead astray from their proper
interpretations within models, but that doesn't mean there still can't be
a better mapping between the two.  (After all, that's what "object-oriented"
is supposed to be all about: oriented toward the real objects we're trying
to describe and perhaps simulate, using the relatively impoverished
software stand-ins we also call objects.)

-Roger