[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PixelArray question



On 8/22/07, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> Sure. And anything else, what might be added to the PixelArray later on,
> as well. As a result we would have a glorious
> can-do-anything-implements-all-python-interfaces class called Surface :-).
>
Smiley notwithstanding, your entire argument that pixelarray
functonality shouldn't be in surface is a Reductio ad absurdum
argument. It presumes that if you would add this one thing, everything
else would also be added. Using that logic, then we should never add
any functionality to Surface - ever - because it would be the
beginning of a landslide of kitchen sinks freely flowing into surface.

The whole point of Lenard's question was that it seems like the
functionality of PixelArray may be appropriate for being part of
Surface, that it may be different from all the things we shouldn't
add. You didn't address why it would or wouldn't be different than all
those things. So basically I don't think your answer addressed his
question.

From my perspective, I think the core issue is whether PixelArray
manages any additional data or state that wouldn't make sense to be in
Surface, or would be easier to use if it wouldn't be in the surface.
If all it's data and state is simply copied from Surface, then all it
serves as an object is boiler plate code for the user to type that
duplicates data from the surface object you built it from.

And in fact, if you look at the constructor for PixelArray, it seems
at first to be exactly that kind of class (one with no additonal state
or data of it's own):
---
    return (PyObject *) _pxarray_new_internal
        (type, surfobj, 0, (Uint32) surface->w * surface->h,
         (Uint32) surface->w, (Uint32) surface->h, 1, 1, (Uint32) surface->w,
         NULL);
---
every argument is copied exclusively from the one surface.

However looking deeper it seems like there are 2 feature where the
pixelarray starts mainting some real data of it's own

first seems to be - slicing. There it constructs a new PixelArray with
parameters that are modified to access a subset of the surface's
pixels:
---
    return (PyObject *) _pxarray_new_internal
        (&PyPixelArray_Type, array->surface, start, end, xlen, ylen,
         xstep, ystep, padding, (PyObject *) array);
---
...however keeping PixelArray as a seperate object but hiding it as an
"interface" would still serve the same goals

the second seems to be that it manages locking the surface over it's
lifetime - so making it an external interface is useful there.


So I think the answer to why it couldn't be part of surface is slicig
& automagic managing or surface locking...