Re: Re: class proposal 3.1

Serge Orlov wrote:

> Mark Hahn wrote:
>> Yes, I agree that an OOPS class is a type, a factory and a blueprint
>> and that type != blueprint.
>
>> I feel that prototypes fill the role of providing types just fine.
>> Don't you?
>
> Yes, as long as they don't try to act as a blueprint at the same time.
>
>> I also feel that my new proposal for "attrProxy_" provides a good
>> way to make factories, independent of protoypes and classes.  Don't
>> you?
>
> Frankly speaking, it feels like a hack. But you'd better as somebody
> else since I'm confined by my proposal :-)

Yes, it is a hack, but a good hack.  :-)

>> If you agree with those two statements, then the Prothon class
>> feature is only left with the job of providing the blueprint. Can
>> you agree with that?
>
> Since I noticed that in your proposal type is fused with a blueprint I
> disagree with that fusion.

That I don't understand.  I will try harder to understand.

>> If you can agree with the above, then we are only left with
>> implementation arguments.  I don't see why you need your instance_
>> attribute
>
> To separate type from blueprint.
>
>> and your factory_ attribute.
>
> There is no factory_ attribute in my proposal. I reused your part of
> proposal (class: label) to allow declaration of simple classes without
> class methods. In general:
>
> class Klass(Base1,Base2):
>     class:
>         <code block1>
>     instance:
>         <code block2>
>
> is compiled into
>
> object Klass(Type):
>     <code block1>
>     object instance_(Base1.instance_,Base2.instance_):
>         type = Klass
>         <code block2>
> ---------------------------
> or if a simplier form is used
>
> class Klass(Base1,Base2):
>     <code block1>
>
> is compiled into
>
> object Klass(Type):
>     object instance_(Base1.instance_,Base2.instance_):
>         type = Klass
>         <code block1>
> ------------------------------------------------
>> Can you explain why my simpler scheme that only has the
>> factory_ (attrProxy_) attribute fails?
>
> How can it be simplier if it changes the meaning of . in a pretty
> complicated way? And there is a special hack to disallow classes to
> act instances? None of that in my proposal. Dot acts as usually,
> classes are impossible to use as instances. Class methods are stored
> where you expect them: as class attributes. Instance methods are
> stored in the blueprint.

I must admit I didn't study your proposal message very closely because it
seemed so complex.  You not only have the instance_ object but you have the
instance_prototype object and the instance_prototype.type_ object.  That is
four objects to my two objects.  I thought you also had a factory object
since you used the "class:" keyword in addition to the "instance:" keyword.

I will go back and study your proposal more closely and respond to it.  I
will try to understand what you mean about types why you need so many
objects.