[spoon-discuss] Why we need OO

[Rob Speer <rspeer@xxxxxxx>]

So, a whole lot of wins or attempted wins have come from the fact that
the rules don't cleanly define what things _are_. Is a Charter a bunch
of text? Is it an object that can take actions? Is it Wonko? Does it
exist at all?

If objects were defined by a class system, then there would be no
question of a Charter possibly being turned into something it isn't.

I was about to propose my OO system. The proposal is kind of large,
because it contains a whole ton of classes - to be precise, as many
classes as are necessary to bootstrap an OO system that is itself OO.

The idea behind the system is that it can coexist with the ruleset, but
eventually parts of the ruleset will be replaced such that the ClassTree
defines what things _are_, while the Ruleset defines what they _do_. 

Now that things are all confused, I'm going to wait until the CFJs go
through or we get things sorted out some other way (I dislike SOEs, by
the way).

But I'll post the current version of the proposal here. If you want to
get to the important part, look at Thingy and Class, which define most
of the system; Object, which almost everything will derive from; and
Unique, a concept that has been sorely missing from the Ruleset. I'm not
defining things like Players within it yet; this is just the foundation
for the system, and changes like that can be proposed separately.

__Be Objective__
{{
1. Destroy the Base class, and repeal rule 1447 [[Class System]].
2. Create a rule:

__Object-Orientation__
{{
Everything in the game is an instance of a Class, as defined in the
ClassTree. If not otherwise specified, it is an instance of Thingy.

Taking X to be the name of any class: if an object is an instance of
class X, or any subclass of X, it can be referred to as "a X" or "an X".
}}

3. Create the ClassTree, which has these contents:
{{
Class: Thingy
Properties:
  * {10} It follows the Rules.
  * {9} It is an instance of a Class.
  * {8} It has all of the properties of its Class, and all Superclasses of its
    Class, except when those properties contradict, in which case:
	  - If a property contradicts a Rule, the Rule takes precedence.
	  - If one property has a Chutzpah greater than the other, that property
	    takes precedence, otherwise:
	  - If both properties come from the same class, the one that is later in
		the Properties list takes precedence
	  - If the class that creates one property is a superclass of the class
		that creates the other, the subclass takes precedence
	  - Otherwise: Take the highest Superclass of the Class that inherits from
		both classes with contradictory properties - the property from the
		class which comes earlier in the Superclass's inheriting list takes
		precedence.

[[Abstract stuff that's needed for a fully bootstrapped OO system:]]

Class: Concept
Inherits from: Thingy
ClassFeatures:
  * Every possible instance of Concept, or any subclass of it, already exists,
    and does not need to be explicitly created.
  
Class: Value
Inherits from: Concept

Class: Number
Inherits from: Value
Properties:
  * It is a mathematical constant.

Class: Integer
Inherits from: Number
Properties:
  * It is an integer.

Class: String
Inherits from: Value
Properties:
  * It is a sequence of alphanumeric characters.

Class: Text
Inherits from: Value [[not String]]
Properties:
  * It is a sequence of words, where whitespace and formatting are not
    relevant.

Class: Reference
Inherits from: Value
Properties:
  * It identifies, in an unambiguous way, a Thingy.

Class: Name
Inherits from: String
Properties:
  * It has a Length which is from 1 to 255, inclusive.
  * It contains only whitespace, alphanumeric, and punctuation characters.
  * It can be used to identify an object iff any of these is true:
     - the name is required to be unique by a Rule or Property
	 - the object's Type is specified, and the name is unique within that Type
	   [[example: "the player Rob"]]
	 - the object can be inferred from context with no ambiguity

Class: List
Inherits from: Concept
Properties:
  * It has any number of members (possibly zero), each of which is a Thingy.

[[ Now, the class that actual game objects can derive from! ]]

Class: Object
Inherits from: Thingy
Properties:
  * It has a name.
  * Its existence is tracked by the Administrator.
  * {3} It is part of the Gamestate.

[[ Oops, a bit more self-referentiality for now ]]

Class: Class
Inherits from: Object
Properties:
  * It inherits from one or more classes, unless it is named Thingy.
  * It has a list of Superclasses, which contains each Class that it inherits
    from, plus all the Superclasses of each of those Classes.
  * It has a list of ClassFeatures.
  * It has a list of Properties.

Class: Property
Inherits from: Text
  * It describes a feature that any instance of a certain Class, or any of its
    subclasses, has.
  * It has a Chutzpah, which is an Integer. The Chutzpah can be explicitly
    given by putting the number in curly braces in the property's text. If
	not explicitly given, the Chutzpah is 1.

Class: ClassFeature
Inherits from: Text
  * It describes something that is true about the class in general, but not
    about instances of it.

[[ We _need_ a concept like this: ]]

Class: Unique
Inherits from: Object
Properties:
  * It is the only instance of its class,
  * It cannot be destroyed.
  * It has a uniquely-identifying name.

Class: Rule
Inherits from: Object
Properties:
  * Its properties are defined elsewhere in the Ruleset [[for now]].

Class: Ruleset
Inherits from: Unique, Container
Properties:
  * It contains all Rules in existence, plus the ClassTree.
  * It is publicly visible.

Class: ClassTree
Inherits from: Unique, Container
Properties:
  * It contains the definitions of all Classes.
  * It is publicly visible [[and for Dave's sake, it can be displayed as
    this flat text file until we come up with a better way to display
	it.]]

}}
}}

-- 
Rob Speer

_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss