[Kde-bindings] KDE/kdebindings/ruby/qtruby/src
Sylvain Sauvage
Sylvain.L.Sauvage at free.fr
Sun Jul 25 15:49:17 UTC 2010
Hi all,
Arno Rehn, dimanche 25 juillet 2010, 17:11:23 CEST
>[…]
> 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.
Yes, because it’s not the object that is const, it’s the
variable (well, not so "variable" anymore ;o) pointing
to/referencing the object. Hence, using const is just telling
the compiler that this variable is const in this function/usage,
it does not modify the object.
In Ruby, freezing affects the object (place), not the variable
(handle, pointer, or reference).
To make my frenglish clearer, in C++:
Object x;
const Object& y = x;
x.non_const_function(); // ok
y.non_const_function(); // compilation error
whereas in Ruby:
l = [1, 2]
m = l
m.freeze
l[1] = 3 # error
m[1] = 3 # error
> 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
Using a block might be less error-prone:
obj.constCalls do |cobj|
cobj.doSomething
end
(Although, I can’t see when const method calls could be really
useful.)
--
Sylvain Sauvage
More information about the Kde-bindings
mailing list