I recently started off learning Ruby using the version 1.8.4 of the Ruby
interpreter.
After some time spent on trying out different Ruby’s specific features I
now may say that it has really impressed me. It’s fun and less coding
than other programming languages which is what I’m looking for.
However, there is something related to OO concepts that I think, in
Ruby, is looking for troubles. More exactly, the encapsulation can be
broken using reflection. Here is a piece of cod that illustrates this:
class Song
attr :count
def initialize(name, artist, duration)
@name = name
@artist = artist
@duration = duration
@count = 0
end
…
def incCount
@count += 1
puts @count
end
…
private :incCount
end
song1 = Song.new(“Ruby Tuesday”, “ff”, 10)
m = song1.method( :incCount )
2.times do
m.call
puts “#”*5
end
Suppose the variable @count is part of the internal state of the object
and it should not be changed from outside the world.
As you can see, I declared the method incCount private as it changes the
object’s internal state
But, surprise, the method is not quite genuine private. It can be called
outside the class using reflection.
My question is if it’s OK to let code outside the class to change the
internal state of an instance of that class? I mean why should we bother
making methods private in the first place if they can be called outside
the class anyway?
Is it a known behaviour or it has just gone unnoticed so far?
2006/6/29, Valentin S. [email protected]:
However, there is something related to OO concepts that I think, in Ruby, is looking for troubles. More exactly, the encapsulation can be broken using reflection. Here is a piece of cod that illustrates this:
As you can see, I declared the method incCount private as it changes the object’s internal state
You can even go further and directly modify instance variables with
instance_variable_set and instance_variable_set.
But, surprise, the method is not quite genuine private. It can be called outside the class using reflection.
My question is if it’s OK to let code outside the class to change the internal state of an instance of that class? I mean why should we bother making methods private in the first place if they can be called outside the class anyway?
Ruby prevents normal usage of private methods but still let’s you use
them if you know what you do. So the answer is, yes, bother to make
things private that should stay private. Anybody messing with the
innards of your classes will be immediately punished if he does it in
non conforming ways - but he can do it if needed. That’s Ruby’s
pragmatic approach.
Is it a known behaviour or it has just gone unnoticed so far?
Umm, Ruby has been around for some while now (meaning years) - such a
fundamental design cannot go unnoticed for such a long time.
Kind regards
robert
Ok. I’ll take it as it is and try to do nice and unharmful thinks with
it.
Thanks
----- Original Message -----
From: “Robert K.” [email protected]
To: “ruby-talk ML” [email protected]
Sent: Thursday, June 29, 2006 1:39 PM
Subject: Re: Reflection brakes encapsulation
2006/6/29, Valentin S. [email protected]:
However, there is something related to OO concepts that I think, in
Ruby, is looking for troubles. More exactly, the encapsulation can be
broken
using reflection. Here is a piece of cod that illustrates this:
As you can see, I declared the method incCount private as it changes the
object’s internal state
You can even go further and directly modify instance variables with
instance_variable_set and instance_variable_set.
But, surprise, the method is not quite genuine private. It can be called
outside the class using reflection.
My question is if it’s OK to let code outside the class to change the
internal state of an instance of that class? I mean why should we bother
making methods private in the first place if they can be called outside
the
class anyway?
Valentin S. wrote:
Ok. I’ll take it as it is and try to do nice and unharmful thinks with it.
Ruby 1.9 doesn’t radically change the model, e.g.
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l18
The same reflection issues are present in Java and C#. I know of no
language and/or runtime that completely enforces protection of private
methods.