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