Re: class proposal 3.1

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?

I also feel that my new proposal for "attrProxy_" provides a good way to
make factories, independent of protoypes and classes.  Don't you?

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?
That is what I meant when I said "The class is a blueprint only".  I meant
the Prothon class feature I was going to propose is a blueprint only, not
the overall total OOPS class functionality.  This distinction is important
because I want the Prothon class feature to be orthogonal with the other
features.

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 and your
factory_ attribute.  Can you explain why my simpler scheme that only has the
factory_ (attrProxy_) attribute fails?