[pypy-dev] Re: type problems

[Samuele Pedroni]

At 17:52 10.07.2003 +0100, Michael Hudson wrote:
>Samuele Pedroni <pedronis at bluewin.ch> writes:
>
> > what I was thinking is that we should see whether a kind of class
> > precedence list (CL, Dylan terminology), MRO can be derived taking
> > delegation into account, e.g. for BoolObject it would be something like
> >
> > Bool Int Any |here starts delegation| Float
> >
> > it would not be just a list of types but a list of pairs
> > (type,delegation_func).
> >
> > With complex it would likely become:
> >
> > Bool Int Any Float Complex.
> >
> > If we can construct such a list, then all the usual MM stuff applies
> > more naturally.
>
>Sure.  This makes sense.  But I'm not sure how (app-side) inheritance
>fits into the picture.

it's a separated issue, or better it is implemented (already now) on top of 
MM,W_* objects and delegation:

1) W_UserObjects delegate to the parent builtin type
2) all the rest is handled by the logic implementing the various space 
multi-methods for W_UserObjects.

>  I guess the "delegation_func" could do this?

now all W_* objects' classes have a dispatchclass attribute that is used 
for MM dispatch (typically w_x.dispatchclass == w_x.__class__, except for 
the synthetic classes used for user-defined types, for which dispatchclass 
is W_UserObject), it should probably become a dispatchcpl.

So dispatchcpl for a user subclass of int would be set to:

W_UserObject W_IntObject ...

The only problem is that it should possible to define conversion delegation 
releationships (i.e. those that are not parent type relationships) where 
the target type is defined, not where the source type, i.e. just like now 
Int-Float delegation is defined together with Float not Int. This means 
that the dispatchcpl lists can be constructed only after all information 
has been gathered and not locally where/when each single type is defined.


>I'm also growing more convinced that what's now W_TypeObject.lookup
>should be a multimethod (and lookup_exactly_here, too, I guess).

lookup probably not, in CPython it's a polymorphic function which basically 
deal with lists of objects having __dict__s.
lookup_exactly_here likely, in the general case it should use getdict, and 
then there would be a specialized version for types that deals with sliced 
multimethods.

regards.