Re: Probing string variables (objects)

[glen e. p. ropella]

[I moved this to swarm-modelling because it raises higher issues
than just implementation.]

Ken Cline writes:
 > Note that if the object (for which a probe display is being
 > created) does *not* respond to `getProbeMap' then a default
 > probe display will be create.

Basically, the approach was for all swarmobjects (and anything
descended from swarmobjects) to be probable (probeable?).  Now,
while collections are ObjC objects, they don't inherit from swarmobject
and, therefore, are not swarmobjects.  So, they aren't really 
supposed to be subject to probing.  Of course, they are, because
the probe mechanism simply uses the object/class structure in
objective c to build the probes. [grin]

This is yet another case of trying to indicate what a tool
in Swarm is intended to do while not limiting the user to 
that particular functionality of the tool.  I.e. we could have
created the probe mechanism in such a way as to prevent String
objects from being probed, since they're not swarmobjects; but
it's obvious that probing non-swarmobjects is useful.

Manor and I talked about this just yesterday in the context of 
restricting the "atOffset" method for collections.  To prohibit
usage of the "atOffset" method for the collection classes where
it is not an efficient way of accessing elements of those collections,
we could ensure (somewhat, at least) that users would not use 
the method in inefficient ways.  So, it's a toss-up between 
limiting the capabilities of the user to only that functionality
that "makes sense" in some given context and giving the user enough
rope with which to hang herself, but with indicators as to what
functionality a given tool is intended to have.  We have *generally*
chosen to let the user do whatever she wants, even if it leads her
to choose satisficing, sub-optimal, solutions.

 > This seems to work okay for me but I haven't tested it
 > thoroughly, of course.  You may want to get a blessing from
 > an SFI developer before changing any of the library code.

Ken's solution looks fine to me.  I wouldn't put it in the release
code just yet, because it's entirely possible that String objects
(or collections, in general) *shouldn't* be probeable.  I.e. 
collections should have some other way of reporting their contents.
A good argument for this way of thinking is preluded by the idea
of a browser for complex objects like Lists and Maps.  E.g.
a linked list would probably be presented in a browser or in graphical
form entirely different than a Stack or a Queue.

But, then, one can think of this "content reporting" as entirely
separate from probing... [grin]  So, obviously, this requires some
discussion.

glen
-- 
{glen e. p. ropella <address@hidden> |  Send lawyers, guns, and money!  }
{Hive Drone, SFI Swarm Project         |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================