Re: Re: Re: Re: class proposal

On Wed, 23 Jun 2004 12:54:03 -0700 Mark Hahn <[email protected]> wrote:

> Lenard Lindstrom wrote:
> 
> > But if you are going to have classes then you should make sure they
> > are used
> > to full advantage. I do not know how Prothon currently handles mro
> > calculations. If it is doing it for every attribute lookup that is
> > too expensive. Certainly it will be for C3. But classes let you
> > calculate the mro once at class creation
> > and keep it around as a list. Much faster.
> 
> Prototypes in general are dynamic and do everything at run-time which has a
> big performance penalty.  MRO calculations are no exception and are being
> done on every lookup right now, although multiple prototypes are rare.
> 
> The solution is through caching just as JIT is the solution for the
> interpreter.  Caching will cache the MRO along with everything else.  This
> will give us the best of all worlds.  Pure dynamic behaviour with high
> performance.
>
> > This is a big topic and I cannot devote the time needed. So to avoid
> > confusing things by making suggestions when I only half understand
> > what is going on.
> > I will sit this one out.
> 
> That is no fun.  If everyone only made suggestions when they understood
> everything it would be pretty quiet around here.  I apologize for booing
> you.  I hope I didn't piss you off.  It was meant as a good boo. :-)  As
> Christian said we are all looking at this from different views.  You are
> probably right anyway.  I'll just never admit it. :-)
> 
> Even when we are somewhat wrong, we trigger thinking in our defending of
> positions.  I learned a lot about Python and about how much Prothon's
> interpreter was really like Python's.
> 
I have classical top-down, modular programming training. This makes me
a procrastinator. Why implement something now if I can stuff it in a
module and worry about it later. Python's low level types - not to be
confused which new-style types - does this for classes. This may have been
by accident. Originally Python classes could not inherit from builtin types
like int. Builtin types became Python language level class only in the last
few years. But the original "type" machinery still exists under the hood.
It is possible that if Python had been designed from the start with new-style
classes that the low level type system would not exist. But I do not really know.

A JIT should give good performance on Prothon builtin types since it bypasses
the entire attribute lookup system when possible. But for third party C modules
a low level type system does have its advantages. Retrieving an operator method,
for example addition on an array, amounts to two C pointer dereferences. Not
even a cache can compete with that.

But if the number of Prothon types is kept at two, prototypes and classes, then
an abstracted type system is probably uncalled for.

Lenard Lindstrom
<[email protected]>