A 'Python like' language

Glenn Andreas gandreas at no.reply
Tue Mar 30 10:25:43 EST 2004


In article <5J1ac.64492$cx5.5801 at fed1read04>,
 "Mark Hahn" <mark at prothon.org> wrote:

> >  So does "foo.bar = 5" add a "bar" slot to "foo" or does it change bar in
> the parent object?
> 
> It took me great trouble to learn to use attribute instead of slot to keep
> Prothon in sync with Python.  I even had to globally replace "slot" with
> "attr" in all my code a week ago, so I'll be replacing your use of slot with
> attribute.
> 
> "foo.bar = 5" will always add an attribute bar to foo.  You have to say
> "parent.bar = 5", or if foo is the current self object, you would say "^bar
> = 5".  The caret(^) prefix reads as "super" and replaces the period prefix
> when you want atrribute lookup to start at the parent of self instead of at
> self.  This was documented yesterday on the website.
> 
> I realize that there is not currently any automatic way to change a value
> found by inheritance.  I'm open to suggestions.  None of the Prothon
> features will be cast in stone until 7/04 so make your suggestions known at
> Prothon mailing lists.

Self gets around this problem by the way it handles assignments as 
method calls, so assigning to a specific attribute/slot/ivar of a 
parent/superclass/prototype is handled like explicitly calling the 
method via a resend or directed resend.

What makes this work is the fact that inheritance is handled by 
"flagging" the slot of the object as something that it inherits from, by 
having an "*" after the name, which results in inerhitance coming from 
explicitly named "paths" rather than some implicit (and usually hidden) 
"__super__" (for example).  So "parent* = anotherObject", "super* = 
anotherObject" and "proto* = anotherObject" all define "anotherObject" 
as something this object inerhits from.  As a result, it is easy to 
explicitly say "parent.foo", "super.foo", "proto.foo" to narrow down 
which thing to inherit from.

Perhaps a similar thing can work for Prothon?  (i.e, explicit "named" 
inheritance instead of implicit anonymous inheritence via "^")?

You could even use "^" for the default "super" (the non-directed 
resend), and then something like "^(anotherParent)" for the moral 
equivalent of a directed resend.

Having named attributes/slots/ivars for inheritence also makes it easier 
to handle dynamically changing multiple inheritence prototypes on the 
fly (since you explicitly have a name for them)



More information about the Python-list mailing list