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

"Christian Tismer" <[email protected]> wrote

> 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 had Prothon operating this way for a while even without the flag so all
objects did this.  It was surprising how well it worked.  This is because
all my test code was just two levels, the prototype level and the instance
level.

This idea is similar to my "call_ str_" proposal.  The only difference is
that you are using the prototype of the prototype for storing the "factory"
class attributes instead of my interpreter kludge to store them in the
special "proxyAttrs_" object.

I claim though that this won't work for more than one level of inheritance.
When using the prototype's prototype for the class (factory) methods, it is
no longer available for normal class inheritance anymore.  How can a class
inherit instance methods from a parent if the parent object is used to store
the class's class methods?

Another way of saying it is that each layer of the inheritance hierarchy
needs two objects if you want dual namespaces to solve the "call_/str_"
problem.  Having each layer use the next layer up for the class methods only
adds up to one object per layer.

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

Every Prothon object has attributes, even the number 5 (remember?).  The
attributes are the equivalent of Python's dict_.  It is accessed by
obj.attrs_.  I have avoided slots because they are only for performance and
add no features useful to the programmer.  They are not dynamic.

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

How does this give restricted access?  Is this a good thing?

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

I'm not sure why you want this.  Is this just for classes or for every type
of object?

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

I can see how the prototype method lookup change helps class-like behavior,
but I don't see how the slots help class behavior.  Attributes are already
sufficient to handle instance data, right?

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

The title of this thread is "What problem are we trying to solve?".  The
problem is certainly not performance.  We should not be optimizing anything
except the user experience and the language design.

I don't want to make things more efficient by making them more static.  I
intend to work on performance later this summer after we freeze the language
design.  My current plans are to do this through caching, not by making
things static.  My personal religion is to make everything as dynamic as
possible and get the performance via caching.  Psyco has proven that a
dynamic language can be extremely fast and we will be implementing Psyco
techniques.  This is the best of all worlds.  If we want static we should
use C++.