Re: Re: What problem are we trying to solve?

Mark Hahn wrote:

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

So let me inject a simple idea and see if it can make sense.

Right now, a prototype is an object that defines behavior
for itself and its "children", aka objects it creates by
being called.
The second part seems useful to me.
But how often are you interested in the initial object
at all, to make operatiing on itself the default behavior?

I believe these cases are rather rare, baybe for singleton
objects. Most of the time, I think the proto itself
provides methods for its kids, and maybe default attributes.

So, let's think of the implication, if the default rule
was changed to not operate on itself?

The special case of protos which *should* operate on
themselves could easily be handled by a flag or something.

But, for instance, most probably nobody is interested in the
root Int object, which is the prototype for all Int objects
and which default value is zero. You will usually just use
the "instances" of Int().

And who cares about that one object at all.

This is just thinking out loud. An object does by default not
define its own methods. Lookup always starts in the prototype.

I think this idea is extensible.
Assignemnts to locals in the proto declaration could be
used as a slot definition with a default value.
The "instances" would by default have slots, not a dict_
(do they have a dict_, I don't know enough, yet).

In a way, this could approach what python is trying to do
with its __slots__ definition: Make instances more efficient.
and have an easily extensible way to add type info and restricted
access. Python does it by adding this feature to the default
__dict__ of instances, by optionally replacing it.

Prothon could come from the other end and do this by default.
An assignment in the prototype decl is a (simplified) slot definition.
It is a design question, whether this should disallow a __dict__
(like in Python), or allow for additional __dict__ as well.
In the latter case, the lookup would first check if the object
has a dict, and look into it, before asking the proto.

Well, as said, thinking loudly.
I guess, it would be better to always look into the prototype.
There the decision is drawn what to do next.
I believe, both the current paradigm could be modelled by this,
and it is possible to model class-like style, too, and both with
only small changes.

If you think this could make sense at all, should I provide
a set of examples how that would look like?

I think (now, 4:00), this engine could stay simple, keeping
Prothon almost as it is, and enabling to behave class-like
with small or no language changes.

This default change would make complicated mro computations
efficient, since they would only take place when a new proto
is declared. All instances created from call_ would use
this efficiently, and I believe this is the most common
pattern of usage, which should be optimized.

now please rip me into peaces -ly your's -- chris

-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/