Re: What problem are we trying to solve?

"Greg Ewing" <[email protected]> wrote

> Mark Hahn <[email protected]>:
>
> > Another way of saying it is that each layer of the inheritance hierarchy
> > needs two objects if you want dual namespaces to solve the "call_/str_"
> > problem.
>
> Here's another dual-namespace idea that's the opposite way around from
> yours. Instead of having a sub-object in the instance for things that
> apply only to the instance, have one in the prototype for things that
> *don't* apply to the prototype.

What you are proposing is what Serge has been proposing:
http://www.prothon.org/pipermail/prothon-user/2004-June/002471.html

He wants to put the instance methods in the sub-object and I wanted to put
the class (factory) methods in the sub-object.

Now I am not arguing for either one of these.  Now I am pushing for Paul's
simpler proposal:
http://www.prothon.org/pipermail/prothon-user/2004-June/002510.html

> This would be more efficient, since it
> means only one extra object per prototype instead of per instance.

I know this barrage of proposals have been very confusing, but I have never
proposed putting anything in an instance except the instance data.

> The extra object could be called 'methods_' since it would be
> used to hold functions that should apply to the instances but
> not to the prototype.

Serge was calling it "instance_".

> The lookup rules would be:
>
> (1) Look in the object.
>
> (2) If the object has a single prototype with a methods_ attribute,
>     continue looking there and in its prototypes.
>
> (3) Otherwise, continue looking in the object's prototypes as usual.
>
> For this to have the desired effect, it would be necessary for
> inheritance of methods to be specified slightly differently.
> Here's an example:
>
>   object MyProto:
>
>     object methods_:
>
>       def str_():
>         return "an instance of MyProto"
>
>
>   object MyOtherProto:
>
>     object methods_(MyProto.methods_):
>
>       def call_():
>         # do something special
>
>   print str(MyProto)      # These both invoke the str_ inherited from
Object
>   print str(MyOtherProto)
>
>   myInst = MyProto() #  invokes the default call_ inherited from Object
>   print str(myInst)  #  invokes MyProto.methods_.str_
>
>   myOtherInst = MyOtherProto()  # default call_ again
>   print str(myOtherInst)        # MyProto.methods_.str_ again
>   myOtherInst()                 # MyOtherProto.methods_.call_
>
>
> One other change is that a directed super call would have to be
> written
>
>   SomeProto.methods_.someMethod{self}(args)

Again, this is Serge's proposal except for fine details like the str calls.