|
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 p.channel<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:
get<red_>(p);
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.
Regards,
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk