Tool class (Long... *real* Long)

[Ken Cline]

Hi all,

I just want to bounce a concept off y'all... 

Those of you who aren't very interested in discussions of
coding techniques, class structuring and the like, may find
the following uninteresting -> boring...

I was thinking that a "tool" class might be a useful
addition to Swarm.  

What is a "tool"? 
----------------------------------------------------------

Well, let me give you a very crude describtion of the OO
programming pardigm as *I* see it, and show you where I
think a "tool" fits in:
    - An object is an encapsulation of data members
      (i.e."state") and methods.

    - An agent is an extension of object such that: 
         - it "exists" in some "context" (i.e. its
           world),
      and 
         - it "schedules" execution of its own methods to
           carry out some prescribed behavior.  

    - A tool is also an extension of object and, like agents
         - it "exists" in some "context", 
      but, unlike agents,
         - it is instructed (by an agent, perhaps) to
           perform some function,
      and otherwise, like an object, 
         - it does "nothing" on its own.

(This "Tool" idea that just something I've dreamed up during
those hour commutes back and forth to work and hence
the logical underpinning of this concept are probably  
extremely weak.  And yes, I have missed my exit a few
times...)

This "Tool" class might have, to start with:
   Data Members:
      - owner
      - user list
      - share setting (Yes, No, By Request to owner, By
               Request to user list)
      - share setting controls (Owner only, any user)
      - static setting (On, Off)
      - static setting controls (Owner only, any user)
      - notification settings (notify Owner/users of
               new owner, new user, removed user,
               change in share settings, change in static
               settings, change of some parameter member,
               etc.  ...)
   Methods:
      - setToolType/getToolType
      - setOwner/getOwner
      - addUser/registerUser
      - removeUser/unregisterUser
      - getCurrentUser (if not self ??)
      - getLastToUse
      - swapOwner (??)
      - swapUser (??)
      - setContext (e.g. world... mainly for bounds
              checking, etc.)
      - getContext
      - canToolBeUsedBy: (id) agent
      - do: (SEL) ThatThingYouDo For:(id) agent
         with: (MagicWord *) "Please" [grin]
      - setStatic
      - getStatic
      - unsetStatic
      - setSharing
      - getSharing
      - setNotification
      - resetToolToDefault
      - resetToolToPrevious

I'm not sure where exactly I suggest to put the "Tool" class
in the Swarm class structure.  Perhaps it would subclass
SwarmObject.  (Maybe I should call it SwarmTool?)


How might a "tool" thingy be used?
----------------------------------------------------------

I think of a tool as being used by one agent, or perhaps
shared by several agents, who only need this tool
infrequently but will use it throughout their "life-times".
That is, its a "waste" to make the tool a data member of the
agent's class, i.e. each instance of agent creates an
instance of tool, but its not really local method variable
either.  Of course, there is no reason to limit a tool's
role to such a specific situation.

Prehaps, an agent would query a "toolbox" within the agent's 
Zone to see if a "type X" tool exists and "is available".
If so then the agent would use the existing tool, otherwise
it would create its own.

If the agent is relying on the tool to maintain a particular
"state" then it could make the tool "static" thereby
preventing its instance variables from being altered, and
maybe even "restricting" use of particular methods, by
other users of that tool. 

Alternatively, the agent could indicate that it "wished" to
be notified that a particular tool's settings/state had been
changed. Either notified when this change took place or when
it went to use this tool for the next time.  Of course this
means that the agent must be able to handle this 
"notification".

For example, we could have the following method in the
agent's class:
   -notificationBy: (tool *) X 
           message: (event *) what_happened {
      if ( [what_happened compare: "something"] ) {
         [ [X getLastToUse] drop ];
         fprintf(stderr,"That'll teach them not "
                        " to touch my bloody tools!\n");
      }
    }

(I have very vindictive agents, no?  ...just had to add a
little levity to see y'all still awake...)

Maybe, a tool would cache its default setup and/or previous
setting so it could be reset after use.  (As my father
always said: "Good little agents always put the tool back
the way they found it." ;-))


A lot of theory... Is there really any practical use?
----------------------------------------------------------

I'm not sure really what a Tool class would get me; when I
was thinking up the idea it seemed really useful. (??)

After reflection, I doubt if there any performance gains
but it might make some stuff more "intuitive" (?).  (Am I
stretching it a little thin?)

I do have one potential use: 

My (I mean, our) agents occasionally "receive" objects from
other agents.  Simple enough, eh?  But some problems
arise in using the received object.  

First, let me make this more concrete, and hopefully
easier to explain...
   - two agents: agent A and agent B
   - one object: object X
   - A "sends" X to B   or   B "receives" X from A
whichever you prefer.

Problems:
   (1) How does agent B assure that object X's data isn't
       altered while B is using X? 
 and 
   (2) Who, agent A or agent B or ???,  has the
       responsibility for dropping the shared object X?

Quick solution:
      Agent B makes a local copy of X.

Drawbacks to quick solution:
   (1) X now needs a copy method. (*) 
   (2) Every data member of X that is also an object
       also needs a copy method. (**)

(* I refer you to list-archive.9702 discussion (amoung
others) about the mixed blessings of copy methods.)

(** I refer you again to list-archive.9702.)

The "tool" solution:
   Agent B registers as a "user" of object X and sets
   X to be "static".

Object X will now drop itself when there are no registered
users or, depending on implementation, no registered users
and either owner == self or owner == null.

Drawbacks to the "tool" solution:
   (1) Overhead!
   (2) We still have a problem with "sub" objects...
       That is, just because object X is "static"
       doesn't assure that one of its data members,
       say object Y, won't be altered.  OTOH, if
       object Y was also a tool...
   (3)    ... [fill in your own] ...


When is this going to end?
----------------------------------------------------------

Anyway, I thought it would be really cool to have this
functionality available at least.  

("Really cool"? ...That's justification, if I've ever 
heard it!)

I have a nagging feeling though that all this might be in
Objective-C or Swarm (or both) in some way.  

(Methaphorically speaking, as good Swarmers should alway do)
I should see what wheels are already in use before I invent
my own :).

Thanks for indulging me for so long...

Ken.


PS   Any ideas how this might fit with the "parameter"
     object that was discussed at SwarmFest?

PPS  Maybe "Tool" isn't a good name for this class... With
     all the owner/user/sharing stuff maybe it should be
     called "Toy"?  Any other suggestions?


Is there an award for the longest posting to swarm-support?
The longest posting that doesn't include any code perhaps?
Am I in the running?  Does the pseudo-code disqualify this
posting?  Do you need a mailing address to send my award to?
Just mail it to: Ken Cline, P.O. Box 1000, Off The Deep End,
MD 21401

_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427