Re: Re[2]: Major change proposal

Lenard Lindstrom wrote:
> >
> > > For me one of the big concerns with Prothon is performance.
Calculating
> > the
> > > C3 resolution order for each attribute lookup is going to be
expensive. So
> > > I am curious as to how well Lieberman's caching scheme will work. I
> > believe
> > > the effectiveness of the cache, more than anything, will determine the
> > ultimate
> > > fate of Prothon. If prototypes turn out to be too expensive then they
will
> > > be regarded as a specialty tool. So will .Net support the cache?
> >
> > Yes, this is a big concern.  .Net has a lot of special collection types
like
> > hash tables and dictionaries.  I'm just crossing my fingers that one of
> > these will work well for my cache.
> >
> That answers one question I had. .Net will be used exclusively. No
external
> C modules implementing Prothon specific objects.
>
> > My biggest concern in this area right now is that I am going to give up
my
> > object locking.  I was going to use that for intelligent cache
invalidation.
> > Lieberman claims in his paper that a dumb scheme will work well. I guess
I
> > will find out.
> >
> > By the way, Guido was commenting over the weekend that he was never
> > convinced the extra work for C3 was really needed.  The 2.2 scheme was
> > pretty good.  As long as you document your scheme a programmer can live
with
> > it.  Of course he also said he thought multiple inheritence was never
really
> > needed either.
> >
> Giving it more thought I wonder just how much extra impact recalculating
C3
> will have. I am only familiar with it in its Python form. It is the
recursion
> that looks intimidating. The C version may be coded more efficiently. Also
> most inheritance is single. So this may make the algorithm trivial in this
> case. And as you mention above C3 may even be overkill. Besides mro
calculation
> is only a small part of the attribute lookup process. If you are not
already
> aware of it Python attribute lookup is complicated. I do not think Prothon
is
> any worse.
>
> Where there is a difference is in variable lookup. The Python compiler can
> replace local variable names with index positions in most cases. But I do
> not see why this is not possible in Prothon as well.

Guido does that with static analysis.  That caused one of the Python
gotcha's (see my VanPy talk).  I don't want to fall back on static analysis.
I'm a gung-ho dynamic freak.