Re: Re: class proposal 2

From: "Paul Prescod"

First of all, let me say that this new scheme with the attribute lookup
interpreter rule has a fundamental problem I don't think can be overcome.
Basing behavior on how the attributes are looked up falls apart when you
start to consider all the method calling requirements.  So arguing about
this proposal is somewhat academic, although not useless.

I have also decided that my proposal is too complex ansd I want to make it
more "contract-like".  Or you could consider it more "interface-like" or
"adapter-like".

> >>I have mixed feelings about having BOTH prototypes AND classes in the
> >>same language...
> >
> >
> > Can you elaborate on your concerns?  Is it confusion?
>  > Performance?  Lack of focus?
>
> Lack of focus. Lack of simplicity. The argument in favor of prototypes
> was that they were simpler and now we are importing the complexity of
> classes (and soon metaclasses) on top of prototypes.

I am convinced that metaclassses are not needed since classes have
prototypes.  This whole class proposal needs a lot more work.  It needs more
work to become simpler and more contract-like.

> Every time people
> create a type they'll have to decide whether to make it a class or
> prototype. And based on what criteria: just whether they are comfortable
> with one or the other? There will be no code consistency.

The behavior of the two are so closely linked that once they are defined
there should be no real difference.

> Which will be the standard model used by the standard library?

If and when we ever get any Prothon language std libs, they would be
specified with classes.  (I am assuming more contract-like).

> > ... I've already given my
>  > arguments for why I want classes included, even though
>  > I personally would use naked prototypes for most applications.
> > I find no conflict between prototypes and classes just as
>  > Python found no conflicts between functions and methods.
>
> Functions and methods do different things. They aren't just there to
> make different people feel comfortable.

I take back what I said.  If classes are implemented properly as a contract
type thing I would use them.

> >>What about inheritance between class attributes? Is there any?
> >
> >
> > Good question.  By definition they would have prototypes, but these
would
> > only matter if you looked up a missing attribute of the attribute.  I
would
> > assume this wouldn't happen so it would be a non-issue.  Methods might
have
> > doc strings and stuff, but nothing that should invoke inheritance.
>
> class foo:
>     class:
>         x = 5
>
> class bar(foo):
>     class:
>        pass
>
> Does bar.x do anything? Does bar().x do anything?

Oh you meant data inheritance.  Yes data would be inherited also.  That is a
side effect of classes being implemented on prototypes.  This will not
affect code ported over because code would not try to access such vars.

> > I only called it a factory in this message.  Nothing is called factory
in
> > the objects themselves.  I'll stop calling it that.  (But Klass.class is
the
> > object that has the call_() method that creates the instances so I
thought
> > that would make it the factory).
>
> Well maybe you are right.
>
> > I'm not sure what you mean.  The instances inherit the methods from
their
> > Class object ("Klass" in the example).  They do not inherit anything
from
> > "Klass.class".  (We need to come up with names for these objects since
you
> > took away the factory name).
>
> Klass.class exists as an attribute.
> Does Klass().class exist as an attribute? Is it identical to:
> Klass().protos_[0].class

Klass() is the instance and it has no attributes when first created.
However Klass().class will work yielding the "factory" object
(Klass().protos_[0].class) through data inheritance since Klass() has one
prototype, namely Klass.