Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-10-25 21:28:41

Lubomir Bourdev wrote:

> "p.x" is much nicer, in my opinion, than "p.x()" and especially
> "get_x(p)". The latter becomes especially unreadable in longer
> expressions.

I agree.

> Unfortunately the most verbose version is also the one that most allows
> external adaptation. To ease external adaptation we would have to move
> everything from a method to a global function taking the object. We have
> done it for some of the methods, but are hesitating to do it for the
> rest. Not to mention some operations simply cannot be moved outside the
> objects, so full external adaptation is compromised anyway...
> Suggestions/opinions/votes are most welcome.

I vote to keep it as it is and... (see below).

>> I believe x and y (and red,green,blue,etc) shouldn't be
>> member variables but "properties", that is, x() and y() (etc)
>> That allows a model to have an array as the internal
>> representation (I know you _can_ have a property interface
>> that uses a named-like syntax as if it were a member
>> variable, but I relly don't like that at all)
> This is exactly the same issue regarding external adaptability, as
> discussed above.
> Note also that "red", "green", etc. are not part of the pixel concept.
> Therefore you should not use the channel names directly in generic code.
> We could provide global functions like get_red(p), set_red(p, x), etc...
> As of now, you can use<0>(), or p.semantic_channel<0>(), or,
> for homogeneous pixels, p[0]

I agree. As I mentioned in my review, these little critters can be made
fully generic and fully adaptable once we adopt them to fusion. IOTW,
the fusion::map *is* the right abstraction for such things. Example:


Take note that adaptation can be non-intrusive (as shown in the fusion
docs). So, I highly suggest keeping GIL as-is and develop color-space/
pixel algorithms on top of it using fusion.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at