Consider ACOP in stead of OOP.

README

@@ -29,6 +29,56 @@ myself
 i
 
 
+
+Rethinking the OOP part: SELSL is focused for use in MUDS and similar.
+Thinking about it pure OOP is a bad fit for that. We can see this from this
+example command: "Move apple from tree to box." On which object this
+command is acting? On the apple as it would seem? But the apple itself is
+basically unchanged, only it's membership changed from being part of the tree
+to being in of box. The tree and box are also changed, but which one of the two
+should get the method then? It does not make sense to define the method on
+either.
+
+Furthermore, there's another object in play and that is the player/actor
+themselves who actually moves the object. In a MUD this may e.g.
+add fattigue to the player, like it does in real life.
+
+And then there is the environment in which these objects may be present,
+or even absent. In a MUD this will be a room in a zone in a land. That room,
+or even other adjacent rooms can be modified by the action of the actor.
+For example a text message may need to be displayed to all other actors in the
+room.
+
+All in all the OOP model is too simple because it put primacy on a single
+object, and defines the operation to one of the involved objects while
+treating the others as second class parameters.
+
+
+What I think would be better for SELSL is ACtor Oriented Programming (ACOP)
+where the actor defines all the operations, but where the environment is always
+an implicit parameter (may be expicit in the Go side). Like this actor
+permissions also become trivial because actors can be defined to only
+know about those actions they are allowed to perform, and furher permission
+checks can be done if necessary before even calling the action.
+
+This shifts the burden away from the actions themselves which might
+then be implemented ignoring permissions since that is checked an a higher
+level. The only exception to this would be commands that can afffect other
+actors.
+
+Of course, then typing does become relevant again, because opening a door
+is different from opening a container. Still it should me possible to overload
+these two operations based on the types of the objects involved. Having
+automatic overloading is easier and more flexible than having to manually
+extend the open operation every time it has to act on some different object.
+
+Of course, all this this goes for object simulation in a MUD-like world.
+For simpler operations like maths or string concatenation, or any pure
+functions without side effects for that matter, the result of the operation
+does not depend on the environment, only on the operands, so maybe a special
+scheme is needed for lower level pure functions or similar operations.
+These might be defined on some kind of "universe" level.
+
 SELSL is object oriented but not class based. In stead it is prototype
 based much like the SELF language. In SELSL, everything is an object.
 Objects have slots that can contain other values. There are basic objects

selsl/acop.go

@@ -0,0 +1,35 @@
+package selsl
+
+type Wherer interface {
+	Find(name string) Object
+}
+
+type Where struct {
+	Wherer
+}
+
+type Actorer interface {
+	Where() Where
+}
+
+type Signature string
+
+type Actor struct {
+	Actorer
+	Actions map[Signature]Action
+}
+
+type Action func(*Actor, ...Object) Object
+
+func (a *Actor) Do(action string, names ...string) Object {
+	objects := []Object{}
+	for _, name := range names {
+		object := a.Where().Find(name) // XXX error checking
+		objects = append(objects, object)
+	}
+	/// XXX caculate signature based on object types.
+	act := a.Actions[Signature(action)]
+	/// XXX error checking
+
+	return act(a, objects...)
+}