A 'Python like' language
mark at prothon.org
Tue Mar 30 23:41:26 CEST 2004
It is not clear to me why the complexity of named prototype paths are needed
right now, but that is not too surprising considering my inexperience with
proto-based languages like self. I will keep the options open as we learn.
It would be especially helpful if "self-aware" programmers tried some small
apps in Prothon in order to give some usage examples. (hint-hint)
"Glenn Andreas" <gandreas at no.reply> wrote in message
news:gandreas-437395.09254330032004 at news.mpls.visi.com...
> 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
> > the parent object?
> > It took me great trouble to learn to use attribute instead of slot to
> > 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
> > 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
> > = 5". The caret(^) prefix reads as "super" and replaces the period
> > when you want atrribute lookup to start at the parent of self instead of
> > self. This was documented yesterday on the website.
> > I realize that there is not currently any automatic way to change a
> > 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
> > 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