Objects, methods, attributes, properties, and other related frobnitzes

[Dan Sugalski]

Okay, just to get some stuff defined and the problem space sorted before I try and work on it:

Definitions:
============

*) Object: An opaque thingie with properties, attributes, and methods

*) Property: A named thing attached to an object. Properties are global to the object and public--i.e. there's no implicit hiding, namespaces, or whatnot. There can be only one foo property on an object, for example

*) Method: Some sort of action that an object can do. Methods are global and public--only one foo method for an object. Methods may be inherited from parent classes, or redefined in a particular class. Redefined methods hide parent class methods of the same name

*) Attribute: A class-private named slot for an object. Objects can have multiple attributes of the same name as long as they're in separate classes, since they're class private.

Behaviours
==========

Now, attributes are *always* data members. They're just slots, at least conceptually.

Properties and methods share a namespace, and methods win. If I do:

a = foo.bar;

I'll call the bar method of foo if foo has a bar method, otherwise I'll fetch the bar property. Python does this (right?) and Perl 6 will do this. (Yes, it will. Inside information, trust me. Unless that changes this week...)

Attributes SHOULD be defined at compile time, but we'll not assume that they will, so we need to be able to add them at runtime. (We'll reserve judgement as to whether this is a Good Idea, since we don't care--we're the "implement semantics" people, not the arbiters of good and bad semantics)

Methods may dispatch based on call signature

Methods will *not* dispatch based on return type

Classes can redefine their methods at runtime whenever they like

Needs:
======

The interpreter must handle the method/property shadowing.

The interpreter must get in the way of method dispatching, as everyone gets multimethod dispatch like it or not (though you don't have to use it)

The interpreter must provide a method dispatch mechanism sufficient to handle the cases we care about, so we can build a reasonable method cache. Otherwise our performance will make a PDP-8 look like a speed demon

The interpreter must handle class hierarchy stuff (parent class, interfaces inherited) so method caches can be invalidated as need be for class structure changes

Code must be able to fetch a handle on a particular method for later calling

Maybes:
=======

Does *anyone* need lexically scoped methods? (i.e. a foo method that's only valid in a particular scope for a particular class, potentially shadowing another foo method)



I think this is all the pending stuff, and our base OO stuff. Comment ASAP--my last mail pickup for a while is 5AM EST Tuesday Feb 4...
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk