Re: Re: Re: Re: class proposal

Lenard Lindstrom wrote:

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

I'm not sure what you mean.  A cache lookup is just a couple of pointer
dereferences also.  Of course you have the overhead of cache misses but
hopefully statistics keeps them from mattering much.

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

I would hope that whatever we come up with for classes is so simple that
they aren't even a first-class type.  I may be crazy but I'm thinking of
something more like an adapter or contract.  As you can tell I'm pretty much
starting over again on my thinking on this.