> class MyUltraSecretKeystore > private > def key > return "nobody-should-read-this-ever" > end > end
> ks = MyUltraSecretKeystore.new
> $ puts ks.send(:key)
>> "nobody-should-read-this-ever"
> *yuk*
> so I can just use [public] for _everything_ as well, right?
It's true that there are many ways to bypass method scope. Ruby trusts us to do the right thing. We consider things like send() and instance_eval() to be tools. They are perhaps dangerous at times, but they are also very powerful. It's a trade-off.
If you're looking for iron-clad laws, Ruby's dynamic nature will probably not appeal to you much.
On Thu, Oct 27, 2005 at 04:32:36AM +0900, Peter Ertl wrote: > Why is this allowed / possible? > $ puts ks.send(:key)
> so I can just use [public] for _everything_ as well, right?
While it may or may not be a good idea that #send subverts access control, your choice of example betrays a misunderstanding of the meaning of "private".
"private" is not intended as a security measure. It's an encapsulation technique. You'll find this is generally true in other languages as well. You can certainly subvert "private" in C++.
"private" exists only to tell other programmers which methods they really shouldn't be calling.
> --- Ursprüngliche Nachricht --- > Von: James Edward Gray II <ja...@grayproductions.net> > An: ruby-t...@ruby-lang.org (ruby-talk ML) > Betreff: Re: how private is private in ruby? > Datum: Thu, 27 Oct 2005 04:38:36 +0900
> On Oct 26, 2005, at 2:32 PM, Peter Ertl wrote:
> > Why is this allowed / possible?
> > class MyUltraSecretKeystore > > private > > def key > > return "nobody-should-read-this-ever" > > end > > end
> > ks = MyUltraSecretKeystore.new
> > $ puts ks.send(:key)
> >> "nobody-should-read-this-ever"
> > *yuk*
> > so I can just use [public] for _everything_ as well, right?
> It's true that there are many ways to bypass method scope. Ruby > trusts us to do the right thing. We consider things like send() and > instance_eval() to be tools. They are perhaps dangerous at times, > but they are also very powerful. It's a trade-off.
> If you're looking for iron-clad laws, Ruby's dynamic nature will > probably not appeal to you much.
On Thu, 27 Oct 2005, Peter Ertl wrote: > not a big deal.. i pretty much enjoy the freedom of ruby!
> I have years of java type safety and design pattern torture > behind me and ruby is the light at the end of the tunnel :-)
> however, wouldn't it make sense to forbid Object#send > when using a specific taint level?
There was a fairly huge thread not long ago on the matter of having two versions of 'send', one of which would include private methods and the other of which wouldn't. I don't think anything was decided, except that Matz didn't like my idea of 'send' vs. 'send!' :-)
> While it may or may not be a good idea that #send subverts access > control, your choice of example betrays a misunderstanding of the > meaning of "private".
> "private" is not intended as a security measure. It's an > encapsulation technique. You'll find this is generally true in other > languages as well. You can certainly subvert "private" in C++.
> "private" exists only to tell other programmers which methods they > really shouldn't be calling.
Exactly right.
I made an analogy the other day with the movie _Apollo 13_. Remember when Bacon's character had been awake for many hours and was, as he said, "a little punchy"? There was a toggle switch which would separate the two modules (and thus doom to death the other two astro- nauts who were spending their time in the other one). He taped a piece of paper over it saying "NO."
> > While it may or may not be a good idea that #send subverts access > > control, your choice of example betrays a misunderstanding of the > > meaning of "private".
> > "private" is not intended as a security measure. It's an > > encapsulation technique. You'll find this is generally true in other > > languages as well. You can certainly subvert "private" in C++.
> > "private" exists only to tell other programmers which methods they > > really shouldn't be calling.
> Exactly right.
> I made an analogy the other day with the movie _Apollo 13_. Remember > when Bacon's character had been awake for many hours and was, as he > said, "a little punchy"? There was a toggle switch which would > separate the two modules (and thus doom to death the other two astro- > nauts who were spending their time in the other one). He taped a > piece of paper over it saying "NO."
> That's how "private" works.
That has got to be one of the best analogies I've read in a long, long time
Tanner Burson <tanner.bur...@gmail.com> wrote: > On 10/26/05, rubyhac...@gmail.com <rubyhac...@gmail.com> wrote:
> > I made an analogy the other day with the movie _Apollo 13_. Remember > > when Bacon's character had been awake for many hours and was, as he > > said, "a little punchy"? There was a toggle switch which would > > separate the two modules (and thus doom to death the other two astro- > > nauts who were spending their time in the other one). He taped a > > piece of paper over it saying "NO."
> > That's how "private" works.
> That has got to be one of the best analogies I've read in a long, long time
Agreed! Though there goes our "come on, it's not exactly rocket science" argument :)
the other way to subvert private (or protected) declarations is to subclass the class with the private methods, and declare the superclass' private method public in the subclass.
On Thu, 27 Oct 2005, Gene Tani wrote: > the other way to subvert private (or protected) declarations is to > subclass the class with the private methods, and declare the > superclass' private method public in the subclass.
I don't think that has any effect. You could, however, reopen the class itself and (re)declare the methods public.
|
