Re: Re: Re: Re: class proposal 2

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?

I think that in these messages I am inconsistent in my use of words and my
logic is bad.  I know what I want in my head but I am not saying it right.

1) I want basic prototypes to be available for 1-tier computing with no
2-tier compromise.

2) I want 2-tier computing to be usable with minimum complexity.  Not all of
OOPS classes features.

3) I want full OOPS classes to be usable as an option with full restrictions
for design-by-contract.

Please correct me if I am wrong, but I think that Paul's proposal is a
solution for item 2.  My "class proposal 3.1" is an attempt at a solution
for item 3.  I think (maybe I am wrong) that your solution is too complex
for 2 and not a solution for 3.

Please don't give up on me.  I know that you are very smart and understand
this very well.  Your proposals are good.  I have used many of your ideas.

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

That is what I called item 2 above.

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

You are correct, both isProto_ and instance_ are hidden.

Disallowing classes to act as instances is a feature of item 3, not item 2.

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

I add them only in item 3.  I add them for people that need
design-by-contract.

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

You are probably correct on both of these last two issues.  I am lazy and do
things in init_ when I should do things in call_.  I will reconsider both of
these items.  I will put them on the to-do list.

I cannot change init_ them until we quit changing call_.