[Kde-bindings] To copy or not to copy

Chris Burel chrisburel at gmail.com
Sat Aug 8 02:00:01 UTC 2009


I'm curious about this code from QtRuby, in it's SmokeClassWrapper
toRuby handler:
if(m->type().isConst() && m->type().isRef()) {
    p = construct_copy( o );
    ...
    if(p) {
        o->ptr = p;
        o->allocated = true;
    }
}

I suppose it's difficult to know when the user would want a copy set
up for them.  But for some things it seems like it's nicer to not
return a copy of the object being returned.  For instance, QWidget's
font() or palette() methods return a const ref, so the user gets a
copy back.  This means that to change a widget's font or palette, they
have to get the font, change it, and set it back.  If a copy wasn't
constructed, whatever changes they make to the font or palette would
take effect without having to call setFont or setPalette, which seems
more desirable (and more like the C++ Qt interface).

The downside I see, if we don't return a copy, that sometimes it would
be confusing because data could change out from underneath the user.
For example, QMouseEvent has a pos() function, which returns a const
QPoint &.  From my experience, it actually returns the *same* QPoint
ref for each event, just with different data.  So if the user is
trying to store positions of mouse clicks and doesn't manually create
a copy, they won't actually save anything.

Thoughts?



More information about the Kde-bindings mailing list