Re: Re: class proposal 3.1

Mark Hahn wrote:
> Serge Orlov wrote:
>> Mark Hahn wrote:
>>> 1) The class is a blueprint only.
>>
>> I disagree. The class is a type, a factory and a blueprint. You
>> should not try to mix the type with a blueprint. Imagine two
>> banknotes: 5 dollars and 10 dollars. Their type is designated
>> in English language with the word 'banknote'. Things you can do
>> with the word 'banknote' differ from things you can do with a
>> banknote. Instead there is an association between the word
>> banknote and a typical banknote image in your head. This idea
>> is captured in my proposal where attribute instance_ acts as
>> an association pointing to a typical instance.
>> Imagine a drunk man who is so drunk that he can't remember the
>> word banknote but still remembers typical banknote. He will
>> say to you "Give me that thing with a portrait". You cannot
>> easily understand what he's talking about unless you start
>> pattern search. That is a "proof" that type != blueprint :-)

> 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 :-)

> 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.

> 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.




  -- Serge