Re: Re: Simple (?) fix for _call and _str

Paul Prescod wrote:

> > I'd like to keep the basic operations like the object keyword
>  > untouched.  We don't want to force 2-tier down their
>  > throats.  Using newProto() would work.
>
> First: I feel like two-tier will be most people's default mode.

Agreed, but we need to keep the basic 1-tier programming constructs like
object intact.

> Second: I'm not sure what you mean by "newProto()" would work? What
> precise syntax would I use to make a new prototype?

I spoke without thinking.  I'm not sure what I meant either.

We can leave object the way it was before and use typeName_ as the prototype
flag and in the syntax it can appear like a decorator:

    object Proto1:
            """Proto1 is a sample prototype"""

            typeName_ = "Proto1"

            def instStr_():
                    blah blah blah

> > You could just use the presence of "typeName_" to indicate that an
> >object is  a prototype and kill two birds with one stone.
> I'd call it
> >"protoName_"  myself.
>
> typeName_ is inherited. The key to the idea is that there has
> to be one
> property that is not inherited. typeName_ *should* be
> inherited because
> when I introspect an integer I want to be able to see that it
> is an integer.

The flag to indicate that an object is a prototype can be inherited also.
The code that checks an object for being a prototype can ignore inheritance.

So typeName_ can serve both purposes if we wish. It can be a prototype flag
for the object it is an attribute of and it can be the name specifier.  The
advantage of having only one is that we can't get in the confused state of
having one without the other.

Forget about my "protoName_" suggestion.  "typeName_" is better.

> > I like your two-name idea for instStr_ and protoStr_.  I
> would want to
> > use str_ and protoStr_ for the same reason that I didn't want to
> > change the object keyword.  I would want the object
> keyword, call_ and
> > str_ to work as before in the default case.
>
> Actually, in my proposal, call_ and str_ do work as before but in the
> docs I would discourage people from overriding them. "Usually
> you will
> want to override instStr_ or protoStr_. If you wish to
> override both at
> once you can just override str_."

Oh, I get it now.

> > Negatives compared to Serge's and my proposals...
> >
> > 1) Lack of dual namespaces.  (You are the one that got us
> started on
> > them <grin>).
>
> True. But it is also in the dual namespaces that everything started
> getting complicated. You can't really have simple directed method
> calling AND separate namespaces at the same time.

Actually, my hack allowed for Python-like directed method calling with the
dual namespaces and your simple scheme doesn't.  The hack is too much to pay
for that feature though.

> > I will vote for this.  How does everyone else feel?
> Comments?  Votes?
>
> I won't vote for my own proposal until I understand better
> what it looks
> like after your amendments. ;)

Do you want me to make a proposal with my change ideas or do you want to
counter-propose?  Our only areas of difference right now are whether the
object keyword changes and whether isProto_ and typeName_ are both needed.