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

[Barry McMullin]

    Since the issue of a -copy method has resurfaced, 
    in the context of the "old" (non zone based) -copy
    having been deliberately broken in 1.0, I thought I might as well
    toss my tuppence worth in the pot...

    I note that there is a Copy deftype in defobj, declaring a standard
    format for a -copy: method that classes *might* elect to
    implement.  I also understand (I think) Roger's concern that
    objects ought to explicitly provide this method, reflecting 
    which vars to copy and/or how deep to copy.  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*.
    That is, I suggesting putting this as a default implementation
    of -copy: at least as high as SwarmObject in the hierarchy.

    This would, of course, be documented with suitable warnings to
    override it if anything other than this complete, shallow, copy
    is required.

    Roger's position on this was:

>The obvious default, if we were to provide one, would be a shallow copy
>of the object's instance variables. That imposes an extra burden on
>user subclasses to override the default if it it's not correct for a
>particular object, however. You've got to be really careful not to pass
>through a default copy: if it doesn't make sense. For example, a copy on
>a space; it shouldn't really go on referencing all the same heatbugs on the
>original space. Avoiding the danger of such inadvertent incorrectness is
>why I've avoided any default up to now. If there's anyone with strong
>feelings we can discuss the tradeoffs. Right now, if you want a
>Swarm-style copy: message, all you have to do is the copy the following
>method into your class:
>
>- copy: aZone
>{
>return [aZone copyIVars: self];
>}

   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 (;-)

   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...

   Oh - finally - I don't think this should be an issue in heatbugs
   anyway.  The demo thing in heatbugs doesn't "really" want a copy;
   in fact, using copy is very bad, because it (transiently) locates
   two bugs in the same site, which is strictly against the rules
   in that app.  What one *really* wants to do is to *create* a 
   fresh heatbug (and initialise it to some selected, empty, location
   in the space).  Presumably the reason this was never considered is
   because one would need access, via a probe, to the HeatBug *factory*
   object; and, of course, the probe machinery doesn't work on
   factory objects.  I suggest that a better thing to do now would be
   to abandon this demo in its current form, and enhance the functionality
   of heatbugs with a different demo: add a "user interface object".  This
   would point to a specific position in the space (this could be easily
   controllable by, say, routing a left click on the mouse to it).
   It would provide a method to create a heatbug on the given site
   (and would refuse this, if there is already a bug there!).  The object
   could create a probeDisplay for itself at createEnd.  One instance
   could be automatically created by the observerSwarm.  This would then
   allow the demonstration of the probe functionality for dragging an
   object pointer, as before; but without confusing the issue by talking
   about "copying" rather than creating, and without accidentally
   contravening the rule about not having more than one heatbug in a
   single site.  As an added bonus, it gives a nice demonstration of
   the concept of designing a dedicated "user interface" object and
   probing it, as a generic approach to user interfacing in Swarm.
   (The only drawback I can see - apart from loading Glen with the job
   of actually coding this - is that we lose the excuse for demonstrating
   the access and use of complete probe displays: but surely we could
   come up with some more legitimate reason for that?)


Cheers,

Barry.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Barry McMullin, Autonomous Systems Group,  |    address@hidden |
| School of Electronic Engineering,          |  Voice: +353-1-704-5432 |
| Dublin City University, Dublin 9, IRELAND. |  FAX:   +353-1-704-5508 |
| http://www.eeng.dcu.ie/~mcmullin/home.html |                         |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++