Jonathon Jongsma wrote: > Hello all. > I've been thinking about playing with clutter lately, so I started > working on some C++ bindings. I've got a couple of questions about > the ClutterColor API. There are several functions which take a src and > a dest color argument. For this email, I'll just focus on > clutter_color_darken(), but the issues apply to several other > functions as well. > > If I was to wrap this API directly into an object-oriented style, I > would end up with something like: > > void Color::darken(Color& dest) const; [A] > > or alternately > > Color Color::darken() const; [B] > > The problem with wrapping these functions in this way is that it seems > to lose some of the flexibility of the C version. For example, with > the C version, you can darken a color directly, or save a darkened > version of the src color in another Color object. For example: > // foo and bar are ClutterColor objects > // darken foo directly: > clutter_color_darken(&foo, &foo); > // make bar a darkened version of foo > clutter_color_darken(&foo, &bar); > > Now, with version A above, we could do both of these cases as well, > but it seems quite awkward to do something like this in C++: > foo.darken(foo); > > Version B above is a more natural syntax, but makes it impossible to > modify the color itself -- the darkened color is always a copy (which > could have some performance implications as well). This also makes > for slightly awkward code in the case where you just want to work with > the darkened color and don't want to keep around the original, e.g.: > Color foo; > Color bar = foo.darken(); > // don't care about foo anymore > > So I had an idea to just modify the src object directly and omit the > dest parameter, e.g.: > > void Color::darken(); [C] > > This means that if you wanted to create a darkened copy of the > original color, you would have to make the copy yourself, e.g.: > > Color foo; > Color dark_foo = foo; > dark_foo.darken(); > > There are drawbacks to all of these options, but I'm leaning towards > wrapping it using version [C]. I looked at what other bindings did, > and it seems that the vala and C# bindings both chose version [A], the > python and ruby bindings both chose [B], and I couldn't figure out > what the perl bindings did :) > > So I guess my question is, which version most closely satisfies the > intent of the API? Is modifying a color directly (e.g. > clutter_color_darken(&foo, &foo)) an expected and common use case? (i > looked at the implementation and it seems that src == dest should be > safe at least). Any other bindings authors care to share why they > made the decisions they did?
The beauty of C++ is that you can have all three functions, although I personally would just do B and C. Of course, whether there is anything other than overhead to be gained by C++ bindings for a C library is open to question. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
