Classes, constants, inheritance and ===

I have been looking at TupleSpaces and Rinda and so on.
I have been trying to figure out how I can have a task list for
workers of differing type.

I want to do something like

space.out([“task”, Admin, [“type”, letter1, letter2]])
space.out([“task”, Manager, [“meet”, board]])
space.out([“task”, Manual, [“paint”, lines, car_park]])
space.out([“task”, Worker, [“attend”, address, “CEO”, date]])

where
class Worker; end
class Manager < Worker; end
class Admin < Worker; end
class Manual < Worker; end

And I don’t want the manager to end up doing the painting, or the
manual staff to do the typing… but I’d like all workers to attend
the address by the CEO…

This means that I actually want to do the matching involved
backwards – normally a template expresses which things I can pickup
from the tuplespace, and === gets the right things. This way round
the tuple determines who can pick it up.

It seems there are >= 3 inforences here:
I am using Linda techniques in a way which is inappropriate, and
a better structure to the space exists
I need to extend TupleSpace to allow this kind of matching,
possibly using kind_of? instead of ===…
I don’t need to extend TupleSpace but because
Worker === Worker is false, I need to fiddle with
x.class.name.intern to get symbols I can manipulate, and
figure out how to get back to a class from the symbol.

Has anyone else run into this before, and did they come up with a
good solution? I still find it odd that Worker === Worker is false!

    Thank you,
    Hugh

I have been looking at TupleSpaces and Rinda and so on.
I have been trying to figure out how I can have a task list for
workers of differing type.
[…]
space.out([“task”, Admin, [“type”, letter1, letter2]])
space.out([“task”, Manager, [“meet”, board]])
[…]
This means that I actually want to do the matching involved
backwards – normally a template expresses which things I can pickup
from the tuplespace, and === gets the right things. This way round
the tuple determines who can pick it up.

My solution was to give each class an instance variable of class
Skillset, on the basis that any class inherits all the “skills” of
its ancestors, shich has an instance variable @skillset which holds
the class of the object that created it, and then and Skillset
implements
def ===(other)
by invesigating the ancestors of other’s skillset, to see if any of
them == @skillset. Thus === is “driven backwards”.

···

On Thu, 19 Sep 2002, wrote:

    Thank you,
    Hugh