From: Meino Christian Cramer <mccramer@...>
Date: 2003-08-17T02:30:58+09:00
Subject: Re: Newbie Q: Data encapsulation with Ruby

From: dblack@superlink.net
Subject: Re: Newbie Q: Data encapsulation with Ruby
Date: Sun, 17 Aug 2003 01:28:22 +0900

Hi David,



> Hi --
> 
> On Sun, 17 Aug 2003, Mauricio [iso-8859-1] Fern�ndez wrote:
> 
> > On Sun, Aug 17, 2003 at 01:02:45AM +0900, Dan Doel wrote:
> > >
> > > P.S.: It's also the case that people can add methods to your class to
> > > access private data
> > > you don't want them to. That's just a part of ruby.  I believe the
> > > #freeze method prevents
> > > that, though.
> >
> > They can also use instance_eval, or add singleton methods to the object.
> > Now, if you cannot trust the people you're working with not to break
> > your design you're screwed, no matter the language or the technology.
> 
> The one sort of "innocent" area where the Ruby attribute conventions
> can also cause breakage is in the return values of reader methods --
> those values being, of course, references:
> 
>   class C
>     attr_accessor :s
>   end
> 
>   c = C.new
>   c.s = "hello"
>   s = c.s
>   s << " there"     # looks innocently local, but....
>   p c.s             # "hello there"
> 
> One can get around this with dup'ing and/or freeze'ing, but I think it
> may just be that the referential nature of Ruby variables and the
> concept of an object being in charge of its own state are somewhat
> in conflict.

  Ooopps.....the newbie's nightmare becomes reality.

  I tend to say, that this side effect is not what I would have
  exspected...

  My innocent (newbie) knowledge may be the reason for it... 


> (One can also get around this by not doing it, but for some reason it
> strikes me as something that could happen inadvertently.)
> 
> 
> David
> 
> -- 
> David Alan Black
> home: dblack@superlink.net
> work: blackdav@shu.edu
> Web:  http://pirate.shu.edu/~blackdav
> 

Keep Hacking!
Meino