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.  Prototypes were
just fine before we started trying to add classes and they will still be
just fine after we add 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.

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

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

I doubt I used the word "just".  I meant that as a complement.

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

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

------

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.