ccMail SMTPLINK Undeliverable Message

[ccMail SMTPLINK]

User ecarr is not defined

 Original text follows 
 ----------------------------------------------
Received: from gate1.dttus.com by cc4.dttus.com (SMTPLINK V2.11.01)
        ; Thu, 05 Dec 96 04:01:16 CST
Return-Path: <address@hidden>
Received: from sfi.santafe.edu by gate1.dttus.com (5.x/SMI-SVR4)
        id AA27446; Mon, 2 Dec 1996 18:16:12 -0600
Received: by sfi.santafe.edu (4.1/SMI-4.1)
        id AA23658; Mon, 2 Dec 96 17:12:08 MST
Date: Mon, 2 Dec 1996 18:11:28 -0600
From: address@hidden (Roger M. Burkhart)
Message-Id: <address@hidden>
To: address@hidden
Subject: Re: Copy and initSeed
X-Sun-Charset: US-ASCII
Sender: address@hidden
Precedence: bulk
Reply-To: address@hidden

Benedikt Stefansson asks:

> And I was also under the impression that copy should be an inherited
> method from SwarmObject, but it doesn't seem to be. 
> 
> If one of the hivemeisters has time to clear up this confusion I would
> appreciate it...

There is no standard copy message inherited for all objects because there's
no general rule for what should be considered part of an object vs. merely
referenced by it.  (In some libraries the extent of an object is sometimes
distinguished as a "shallow" vs. "deep" copy, but what those mean can be
highly object specific, and must end up being specifically coded for each
object type.) For some objects that are deeply entangled in references to
other objects, it may not even be valid or meaningful to attempt to copy
the object as a new instance.  (This is true of some schedule components,
for example.)

What this means is that if you want a copy message, you can still provide
one; we just don't provide any default inherited method.  You have to code
what makes sense for your objects yourself.  For objects on which you want
to support a copy operation, you provide your own copy method.  If we had
multiple inheritance, we might be able to provide a way for you to
selectively inherit a default copy method from another class when you want
it, but since we have to bundle up all inherited methods into a common
superclass, we don't provide it there by default.

If you provide a copy: method, you should use the [anObject copy: aZone]
form suggested by defobj and followed by existing copy: messages.
If you want to copy just the local instance variables of an object, and
not anything it points to, the following method should work:

- copy: aZone
{
  return [[self getZone] copyIVars: self];
}

We could bundle up this code in a function someplace, but since it's
a single statement for now we just leave it for an implementor to provide
if this stand-alone form of copy makes sense for your objects.

An argument could be made that this default method could be provided on
SwarmObject for use by all subclasses unless overridden.  That would
impose a burden on all subclasses to disable the method when it didn't
make sense, however.  The times when the default method doesn't make sense
can be surprisingly often, for example whenever the object contains
pointers to other allocations that aren't guaranteed to be shared.  We
avoid the potentially error-prone default in favor of being explicit about
what copy action is supported you do want it on an object.  Objects should
not be assumed to support copy: unless they specifically document that
they support it, and even then they must say what exactly is copied when
you call it.

Roger Burkhart