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

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

Agreed. Paul's proposal is a solution #2.

I don't see *a lot* of complexity in my proposal, but I'm biased.
I see why you need restriction on classes for your proposal but I
don't understand why do you want to impose restrictions for classes in
general? See the questions below:

> 1) The class ... cannot function as an instance.

It's true for my proposal by design.

> 2) The class is immutable.  Once defined it cannot have class or instance
> methods added, removed, or redefined.  Class variables cannot be added or
> removed but their values may change.

I don't see why this restriction should be applied for my proposal.

> 3) Instances may have only data attributes.  No instance methods are
> allowed.

Why is this restriction needed in general?

> 4) Instances only inherit from their one class.  All inheritance is through
> their class which inherits only from other classes.

Instances in my proposal inherit from one blueprint too. The ability
to change prototype list is a question for me in general. I have
already asked why does one need to change prototype list after object
construction.

> 5) Class and instances will have seperate namespaces due to the call_/str_
> proposal fix that works for prototypes and classes.

Two namespaces by design in my proposal.


> ... I have used many of your ideas.

You are free to toss my ideas away as well :) I don't have a lot of time
nowadays because I started a new dayjob. OK, I'll stay subscribed to
the list, but don't except a lot of feedback and ideas from me, I will
also try avoid time-consuming controversial topics ;-)

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

[snip]

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

Like Paul, I'm concerned with two not so different ways to do programming
in one language. I also don't see the connection between classes and
design-by-contract.

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

Nice to see you decided to clean up what have been done during last
months. It's impossible to do everything right since the beginning,
but you still have time to correct before it will become a regret
and it will be hard to correct or remove. I'm sure there is still
something in the language you will regret in the future but we
don't see it yet.

  -- Serge