[pypy-dev] W_XxxObjects

[Armin Rigo]

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

This would not change anything at all for the code in pypy.interpreter. It
would only be meaningful to the internals of objspace.std. It would mean that
if we know, say, that "W_StringObject = str", then we would know that for
reasonably short strings space.wrap("hello") is actually just "hello", thus
removing some boilerplate.

This *only* applies within the StdObjSpace. Code in pypy.interpreter cannot
assume anything like that. Also, it does not prevent alternate implementations
of integers or strings to coexist; they would be done as usual with, say, some
new W_VeryLongStringObject, which is unconcerned about the existence of the
previous string implementation as "W_StringObject = str".


As a possibly clearer alternate to that, defining a delegation from
"W_StringObject" to "str" would be a matter of two lines of code, and would do
the transparent unwrapping you mentioned.

Damn, I have again been changing my mind between the start and the end of the 
e-mail.


A bientôt,

Armin.