Re: Re: Re: class proposal 2

Mark Hahn wrote:
> Serge Orlov wrote:

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

No, it is not used anywhere. .type_ of a class is there for
completeness so that you can find out the type of any class related
object like classes or objects instantiated from classes.
It has the same purpose as Object.protos_[0]. It is possible
to remove it from classes but then type(Klass) will be == None

> 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 specifically removed them. It's dead easy to add them to my classes.
As I said above there is one type of class, I don't want any more
of them.

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

Sure. I was not trying to reproduce Python classes with their
problems. If I want Python classes I will use Python.

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

It is more compatible with the past, but that does not make it better.
(or well, it does make them better from compatibility point of view)

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

That is the curse of prototypes. Other people has already pointed
out that prototypes are too low level. I feel the same. If you try
implement even such basic things as classes, you will end up with
hacks, workarounds, fixes or hidden objects. On the other hand
I need types, classes and instances because they are useful. I
asked my coworkers and they also said the same. Prototypes are
too low, they need classes.

My proposal is also implementable in any prototype language. (apart
from :: syntax of course, but blueprint is still accessible anyway
in my proposal as Klass.instance_)

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

I disagree. I do not try to workaround any problems so my
implementation is neither a hack nor a workaround nor phony. I write
definitions and follow them. My design is a reflection of definitions.
Your design is titled "What problem are we trying to solve?"
http://www.prothon.org/pipermail/prothon-user/2004-June/002426.html
You write down small problems and try to solve them. That's two
different approaches. When I posted my small review titled
"Types in 1-tier system", you said it's just an entertainment reading.
Mind you, I'm not offended at all (it's hard to offend me and I don't
think you have to read everything what I write). My point is that
we follow different approaches. IMHO your method of design prone
to hacks and workarounds because you're concentrating on problem
solving. Mind you, I'm not going to try to change your ways,
I know how futile it is to change somebody's way (including mine),
so I'd better quit this topic.

While I'm at design here is another rule: Removing features is much
harder than adding them, the sooner you remove doubtful features
the better.

1. .init_ returning something. The problem is that an instance method
is trying to act as a factory.

2. Ability to change prototype list. That feature should not be
exposed to ordinary users, they don't need it, let them add prototypes
only in the Object constructor. I don't know any legitimate
uses for changing prototype list, what are they?

  -- Serge