[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