A 'Python like' language

[Mark Hahn]

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
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)