Re: What problem are we trying to solve?

Paul Prescod wrote:
> Perhaps some of the traffic around classes derives from the fact that
> we're trying to solve different problems. This whole thread seemed to
> start with two issues:
>
>   1. call_() on "instance objects" is non-intuitive and hard to
> override.

To be picky, call_() is easy to override, but when you do you are also
overriding the prototype's version, which is the real problem.

>   2. str_() on "instance objects" is non-intuitive and hard to
> override.

Again, to be picky, the problem is that str_() for prototypes is often not
what people want.  Str_() for instances is no problem.

> There are solutions to these problems that involve minimal or no
> language change.

Then let's get these established by proposing them.

> Another stated problem is that people coming from Python just feel
> confused by the prototype model. But if the prototype model is truly
> simple, they'll pick up on it quickly. So I personally feel that this
> is not an important problem to tackle.

I probably worry about this more than others.  Python already has
acceptability problems in corporate world because of dynamic typing and lack
of contract features.  I'd like Prothon to be more acceptable to this world,
not less.

Let's take one small example.  If the class object was immutable so that
someone couldn't do this, it would make a contract-lover happy:

    object WidgetProto:
            def methodA():
                    blah blah blah

# totally different file
    with WidgetProto:
            def methodA():    # redefine methodA
                    different blah blah blah

> Are there other important problems to be solved?

Of course, but we have this problem in our mindset now, no matter how small
it is.  Let's move on by getting this one solved, not by sweeping it under
the rug.  If it really is a small problem then it should be easy to solve.