Re: can't do addBug via probes in heatbugs anymore?

[Roger M. Burkhart]

Barry McMullin suggests including a default form of the deliberately
broken default copy method in 1.0:

> On the other hand:
>    it seems to me that it would not be *too* dangerous to make
>
>      [[self getZone] copyIVars: self]
>
>    (i.e. a complete but shallow instance var copy) the *default*.

Barry McMullin does a good job of accurately laying out multiple sides
of this issue:

>    I don't really buy this: by omitting the default we impose
>    a burden on all classes for which a copy method is required - 
>    *both* those for whom the default would work and those for whom
>    it would not; whereas, with a default we only have the burden
>    of overriding for the smaller set of classes where the default
>    will not work. (I'm implicitly discounting all those classes
>    for which the default would not "work" satisfactorily, but where 
>    copy is never invoked; there is no need, and therefore no
>    burden, of overriding there...)
> 
>    Of course, as Roger says, by putting in the default, we open 
>    the danger that someone will blindly use the default, without evaluating 
>    its suitability (or making the wrong assumption about its semantics,
>    without reading the docs (:-( and be totally confused by the
>    resulting coredump or whatever.  Arguably, by not providing a
>    default, we force the user to think about the issue and make
>    some explicit decision.  On the other hand, my guess is that the
>    users who would have fallen foul of the default are fairly likely
>    to now just explicitly program the default and *still* fall foul
>    of it.  But I guess that really is their own fault (;-)

It all comes down to the values placed on correctness vs. convenience.
My call so far is that if we can make it convenient enough to do the
correct thing, it's better to make the programmer do it explicitly so that
some thought has to be given.  Adding your own code for copy: method isn't
as convenient as it should be (I'd prefer to be able to multiply inherit
it from some standard source, but ObjC doesn't give us that), but in this
case the code is so simple that I don't see the case for convenience over
correctness as having been made yet.

>    Maybe the danger here could be avoided
>    by using a more obscure/cumbersome method name -
>    something like "-shallowCopy" or "-simpleCopy" or even
>    "-simplisticCopy" - but that detracts from trying to have a 
>    "standard" name that always means the "correct" kind of copy,
>    whatever that may mean for the particular class...

One goal of Swarm has been to keep the set of basic, built-in interfaces
reasonable small and uncluttered, without the kitchen-sink lists of message
name variants found in many object libraries.  We take some grief sometimes
for being so minimalistic in our provided interfaces, but I still think
that not being too prematurely ambitious on convenience features pays off
in simpler, cleaner packaging of more basic function that remains easier
to learn.

In the case of copy, you point out that a copy in heatbugs is the wrong
model anyway, and some other create messages should be provided for demo
purposes instead.  I think it's often the case that the right way to
interpret a copy inside some embedded context isn't clear.  It starts a
design on better grounding to say that a model doesn't have any behavior
except that which you decide, explicitly, to add to it, and right now this
still includes copy.  Perhaps this consideration, what encourages the
better design, is what should really decide the default copy question.

-Roger