[pypy-dev] W_XxxObjects

[Samuele Pedroni]

At 16:41 16.06.2003 +0200, Armin Rigo wrote:
>Hello Christian,
>
>On Sun, Jun 15, 2003 at 04:39:13AM +0200, Christian Tismer wrote:
> > >It seems to me that the first implementation is a typical example of the
> > >boilerplate kind of code that we hoped the project would remove, isn't it?
> >
> > It is the kind of code that *you* introduced into the project.
> > Your new definitions seems to do an unwrap before calling the
> > function. Or aren't they even wrapped?
>
>Sorry about that, I tend to write long confusing e-mails about subjects that
>keep evolving a bit in my head. I will try to avoid that in the future
>(probably just writing an e-mail, trashing it, and writing it again the next
>day would be a good start).
>
>In that case the changes I proposed are not as big as they might seem. To make
>it short, say for integers for example, they would just amount to defining
>"W_IntObject = r_int", instead of a class with a single field which is an
>r_int.
>
>So code like that:
>
>     def lt__Int_Int(space, i, j):
>         return space.newbool(i < j)
>
>would work just because W_IntObject is r_int. There is no auto-unwrapping
>magic; the r_int is the wrapped object -- as well as the unwrapped one, which
>is I admit not much help in clearing the confusion. (It might thus not be such
>a good idea -- although it would certainly be a boilerplate-reductor.)

If we want to reduce the boilerplate and avoid the confusion we should 
really think in terms of auto-unwrapping.

In terms of a translated impl r_int is an unboxed int, W_IntObject a boxed 
one. It is true that as long as we are hosted by CPython and it is 
implicitly clear what is boxed/unboxed we can use the same objects for 
wrapped(boxed)/unwrapped(unboxed) values for some types and have 
wrapping/unwrapping be the identity for them. It is also true that having 
code in terms of unboxed objects is maybe better to generate instruction 
sequence templates for native code generation.

But for a translated impl. wrapping/unwrapping won't be no-ops.  So the 
code is probably clearer for the uninitiated as it is. If we want to reduce 
boilerplate we should add some auto-unwrapping/wrapping logic where it can 
make sense.

regards.