class proposal 2
"Mark Hahn" <[email protected]>
| Newsgroups | gmane.comp.lang.prothon.user |
|---|---|
| Message-ID | <[email protected]> |
I hope you'll forgive all these postings, but I don't have a day job like
the rest of you :-)
I've got a two-tier class proposal that is more concrete than my old one.
It is mostly based on Serge's proposal but I feel Paul's thinking is
incorporated. As always feel free to shoot holes in it.
There will be a class object for each class. This class object will have
the traditional OOPS meaning of blueprint for an instance of the class. It
will be implemented as a prototype for the instance objects with methods
that instances delegate to. It's prototype list will point to other classes
giving the normal class inheritance heirarchy.
There will also be a factory object for each class. Ironically this object
will represent the class itself instead of the instances even though it is
not the "class object". Class methods and class variables will be stored
here especially the "call_" method that implements the "Class()"
constructor. I will explain how this works in a moment. This gives a
seperate namespace for class attributes.
If the Class object is called "Klass", then the factory object would be
stored in it's attribute as "Klass.class". Access to class methods inside a
normal method or inside a class definition would be through the normal
"Klass.class.method()" or through new syntax sugar that makes use of the
class keyword as a prefix "class.method()". Likewise Class variables could
be stored as "Klass.class.x" or using the new prefix "class.x".
The interpreter would have special knowledge of attributes named "class."
This is not surprising since keywords aren't usually allowed as attribute
names. In all attribute lookups a special rule will be used:
--- "class" attribute special lookup rule ---
--- When an attribute is first being looked up in an immediate object, not
an ancestor, and a attribute named "class" exists in the immediate object,
that class attribute object is used in the object's place for the
lookup. ---
This rule is the only special interpreter hook needed for class behavior.
It will redirect class attribute lookups to the class factory object and
allow instance method calls to continue to go to the class object. Thus the
construcor call "Klass()" will work using "Klass.class.call_()" and "kls.()"
will work from an instance kls using "Klass.call_()".
Now for the syntax. This is pretty much just the object structure outlined
above. Here is an example:
class Klass(Parent1, Parent2):
"""Class document string"""
class:
name = 'KlassType'
instanceCount = 0
def str_():
print '<class Klass>'
def count():
return instanceCount
def init_(x, y):
self.x = x
self.y = y
class.instanceCount += 1
def str_():
print '<Klass:'+self.x+'/'+self.y+'>'
Note that I really get a lot of use out of the class keyword in this
proposal! :-)
This is just like the Python class statement except that there is an
optional class section with a compound-body of class methods and class
variables. The class variable "name" would actually be produced
automatically without the explicit statement here.
This is inside-out from serge's proposal which had the class object inside
the factory object. I think my ordering is important because we need to be
able to use the directed "Klass.method()" call syntax which wouldn't work
with the factory as the class name.
Serge's implementation code will still work with some tweaking:
object Klass(Parent1, Parent2):
"""Class document string"""
<outer class: compound-block>
object class:
name = "{KlassName}Type"
def call_(*args, **kwargs):
instance = newObject(self.container_) #
container == Klass
instance.init_(*args, **kwargs)
return instance
def str_():
return name
<inner class: compound-block>
Note that the Klass.class "name", "call_", and "str_" attributes can be
overriden in the inner class block. class.container_ is automatically
created by the compiler to point back to the Klass object.
Comments? Votes?