Re: Re: Re: Re: class proposal 2

Mark Hahn wrote:
> Serge Orlov wrote:

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

> The reason we ended up with hacks and hidden objects is because we were
> tyring to add an overly complex thing to prototypes, not because prototypes
> are overly-simple.  You can do everything without classes.

Why add classes then?

> Prototypes were just fine before we started trying to add classes and
> they will still be just fine after we add classes.

What you had Cristian correctly called flattened classes. So what you
will have soon is classes with fixes plus flattened classes.

> Look at Paul's proposal.  His does not add any hacks or hidden objects
> because he is not trying to add overly-complex classes.

His proposal is a workaround (a fix as he calls it). What makes
his .isProto_ not hidden and my .instance_ hidden? Both are set
by the classes processor which processes class syntax and creates
objects (a boolean in his proposal). I don't also understand
how his proposal disallow classes to act as instances.

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

> You need types and instances.  You don't need classes.

Why do you add them?

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

> Sometimes you realize when in the middle of an init_ that changing the
> object would make things much simpler.  I have found three or four valid
> places where I use this in my code.  A singleton is a great example for this
> usage.  You just return the prototype and every instance is the prototype.

It's a job for the default factory method .call_() not for .init_()

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

> Changing type is a valid operation that I also do all the time.  Tutorial
> section 6.6 covers it with a simple example.

should be in the factory method again. It seems like you do not work
as I do. You do not want to think how to remove them, instead you
think how to *keep* them. As I said our principles differ.

> I have an idea.  Since your proposal involves no hacks, why don't you
> implement it in Prothon and let us play with it.  You could write some app
> code in your scheme and we'd port it to our scheme and compare the results.

If Paul workaround fulfills your goals you posted in one of your
letters why waste time? I'm not arguing about implementation per se,
I'm arguing about design. We disagree, so I'd better sign off.

  -- Serge