[Kde-bindings] KDE/kdebindings/ruby/qtruby/src

Arno Rehn arno at arnorehn.de
Sun Jul 25 15:11:23 UTC 2010


On Sunday 25 July 2010 16:57:07 Richard Dale wrote:
> On Sunday, July 25, 2010 03:22:35 pm Arno Rehn wrote:
> > SVN commit 1154467 by arnorehn:
> > 
> > Choose the const/non-const version of a method based on whether the
> > object is frozen or not. 'Frozen' objects in Ruby roughly translate to
> > const objects in C++, so this should work out fine.
> > Quick testing with the QDBusArgument API (which now doesn't need special
> > casing anymore) worked well.
> 
> I'm not sure that freezing ruby variable to force const/non const method
> overload resolution is a good idea. Once you have frozen a variable you
> can't unfreeze it, and i'm sure some variable being used with dbus will
> need to be updated after they have been read from. Also it doesn't feel
> like a Ruby idiom to freeze/unfreeze to get the api working - I would
> rather have different names for the methods to read and to write.
I just thought that frozen objects represent C++ 'const objects' best: You 
can't modify const objects and you can't modify frozen objects.
Casting away the 'const' from a C++ object is generally regarded as a bad 
idea, so not being able to unfreeze an object seemed like the right thing.

Thinking about it again, it could happen that an object should only be const 
in certain situations and then being unable to unfreeze an object would really 
be bad.

In any case, I think having a special method/property to enable or disable 
const method calls would be best, like

obj.constCalls = true
obj.doSomething
obj.constCalls = false

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list