Re: Re: class proposal 2

Serge Orlov wrote:

> Paul Prescod wrote:
>> Serge Orlov wrote:
>>> That's two pretty contradictory statements. Will you not add
>>> classes or will you search and add? At this point of discussion I
>>> pretty much convinced myself how classes (which act like types)
>>> should be implemented. I will sit and watch if somebody suggests
>>> something better. I'm skeptical today.
>
>> There is too much traffic for me to keep up. Is there one post that
>> summarizes your position? My last impression of it was similar to
>> Mark's. It did seem as if it was getting complex.
>
> Yeah, the traffic is getting heavier. I'd like to clarify my
> opinion on metaclasses. I think they were overdesigned in Python,
> they act as decorators. So classes either from Type or .copy() Type
> in my proposal, but they are there just to complete the whole
> picture so you can find out type of everything. There no a lot
> of usage for putting other methods besides .call_() and .str_()
> into any metatype, so what I want to do is to kill metaclass
> right now. There should be one immutable metaclass named Type
> with two simple methods .call_() and .str_(), no other metaclasses
> allowed.

Does this mean that the type_ variable is only used for printing in the str_
method?

> Classes are defined as:
> class Klass(Base1,Base2,...):
>     class:
>         <class methods here>
>     instance:
>         <instance methods here>
>
> if there are no class methods a short declaration can be used:
> class Klass(Base1,Base2,...):
>     <instance methods here>
>
> No matter how instance methods are defined they are stored
> in the prototype instance_ which is an attribute of the Klass.
> If you want to make a reference to instance method you can
> do it as Klass.instance_.method or shortcut syntax Klass::method.

That Klass::method syntax doesn't relate to any other syntax in Prothon.  We
would need something different or just stay with Klass.instance_.method.

> Direct calls can be spelled as Klass::method(a,b,c) which is
> equal to Klass.instance_.method{a}(b,c)
>
> Class methods are stored as attributes of the class. So if you
> define
> class Klass(Base1,Base2,...):
>     class:
>         def fromFile(name):
>     instance:
>         def fromFile(a,b,c)
>
> and call Klass.fromFile(s) then *always* class method will be
> called without any exceptions for call_, str_ etc...
> if you grab the reference Klass.call_ you will get class method,
> if you want instance method you will spell it as Klass::call_
>
> All instances inherit from Klass.instance_ prototype. It's
> an object that inherits from Base1.instance_, Base2.instance_
> and has an attribute .type_ which is equal to Klass. In one
> of my letters I said "every object has type_ attribute". This
> is incorrect. Every *instance prototype* has type_ attribute

> The follow code describes it in code:
>
> class Klass:
>     pass
>
> k = Klass()
> assert k.attrs_() == {}
> assert k.type_ is Klass
> assert Klass.instance_.attrs_[$type_] is Klass
> assert k.protos_[0] is Klass.instance_

The main difference I see between your proposal and mine is that you store
the class methods in the outer object and the instance methods in the inner
object and I do the reverse.

We both have the prototype of the instance be the object  that holds the
instance methods and this instance prototype has as it's prototypes the
class base prototypes.

We both have no support for metaclasses at this time.

I could add a "name" variable to my scheme (which you call "type") so that
my str_ would have something to print for the class aslo.

My scheme allows the normal Python-like directed method calling of
"Klass.method()" where yours doesn't and mine can refer to an instance
method as simply "Klass.method" where yours requires some special new
syntax.

Mine requires the use of special syntax to refer to class methods and class
variables where yours doesn't.  We have just reversed which type of
referrals have problems since we reversed what the Klass object holds.  I
argue that instance methods are more commonly referred to than class methods
of course so my way is better.

Mine is more intuitive in that the Klass object is the prototype for the
instance instead of a hidden object.  Mine also doesn't have the hidden
object at all in the common case where call_ and str_ are not overriden.
Yours always has the hidden object even in the most simple cases.  Thus I
claim mine is simpler for the user.

Mine requires an ugly hack inside.  I'll gladly put an ugly hack inside if
it makes a better feature outside.

Now that I understand your proposal and how it is so much like my "str_
call_" proposal, I have no idea why we were even discussing blueprints and
types.  Our proposals don't differ at all in in regards to blueprints and
types.  I also realize that my seperation of blueprint and types is phony
(as is yours).