swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: glen e. p. ropella
Subject: Tool class (Long... *real* Long)
Date: Thu, 20 Mar 1997 10:01:57 -0700

Ken Cline writes:
 > I was thinking that a "tool" class might be a useful
 > addition to Swarm.  

Killer idea!

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

OK.  The "'exists' in some 'context'" doesn't really help
me.  But, if you mean to say something like:

  - object => passive encapsulation of data and function
  - agent  => active encapsulation of data, function, and motive
  - tool   => reactive encapsulation of data and function with
              dynamically defined motive

then I might understand it.  But, without specifying the motivation
(or, to be a politically correct alifer, allowing the motivation to
emerge [grin]), there doesn't seem to be much difference between a
tool and an object.  And if this is the type of scheme you have in
mind, then the word "pawn" might be more reflective of the role this
type of thing plays.

I'd like to open up the can of worms to the group and ask you guys,
"What is an agent?"  There's a guy here at the institute who wants to
define agents as 'entities that act on their own behalf' or somesuch.
That seems to add a further restriction on the definition by requiring
that an active object be self-serving before we can call it an agent.
In ethical theory, they have a similar extended requirement that says
to be a "moral agent," one has to have an "interest" in the outcome of
any transaction or process.  Of course, this doesn't mean that "just
plain agents" who don't have an "interest" are not agents... but,
"moral agents" are the only operative agents in ethics.

It might be nice to have a common "Swarm-style agent" defined so that
we can know what we're talking about.

 > 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?)

Actually, what you're doing, Ken, is defining an entire library.  I
suggest that Ken start a tools library! [grin] Then we can have all
different kinds of tools in that library.

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

These are probably modelling issues.  I would make the 
tools configurable such that they could be shared by 
cooperating agents, fought over by antagonistic agents,
and instantiated by inventive agents.  There might be 
several options for handling competition for the resource,
notification of freed resources, etc.

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

Yep!  That is justification.  If you're not having fun
at your job and coming up with "really cool" stuff, then
you probably ought to look for another job. [grin]

 > 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

No.  But, there should be.  Or maybe there should be a punishment
for one-liners.  Hmmm.  Anybody out there studying email list
dynamics?  

glen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]