From: Valentin Samareanu <vsamareanu@...>
Date: 2006-06-29T20:07:11+09:00
Subject: Reflection brakes encapsulation

------=_NextPart_000_01A3_01C69B84.FEE0EDE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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     =3D name
    @artist   =3D artist
    @duration =3D duration
    @count =3D 0
  end
...
  def incCount
    @count +=3D 1
    puts @count
  end
  ...
  private :incCount
end


song1 =3D Song.new("Ruby Tuesday", "ff", 10)
m =3D 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?

------=_NextPart_000_01A3_01C69B84.FEE0EDE0--