how private is private in ruby?
Peter Ertl
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?
Best regards
Peter
James Edward Gray II
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.
James Edward Gray II
Edward Faulkner
> Why is this allowed / possible?
>
> 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.
regards,
Ed
Peter Ertl
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?
> --- Ursprüngliche Nachricht ---
> Von: James Edward Gray II <ja...@grayproductions.net>
> An: ruby...@ruby-lang.org (ruby-talk ML)
> Betreff: Re: how private is private in ruby?
> Datum: Thu, 27 Oct 2005 04:38:36 +0900
David A. Black
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!' :-)
David
--
David A. Black
dbl...@wobblini.net
rubyh...@gmail.com
Edward Faulkner wrote:
>
> 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.
Hal
Jeremy Kemper
Hash: SHA1
In current Ruby 1.9 you may not send private methods. I don't know
whether this is an experiment or a permanent restriction.
Regardless, you may ks.instance_eval { key } anyway, though in
this case at least you have $SAFE at your disposal.
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFDX+CVAQHALep9HFYRAlV3AJ9BEHcb5Xmb8qRLS09A8KXJCIU4sQCfQroC
k0r75fKUoI5Z3UiE0upzDc8=
=X4SS
-----END PGP SIGNATURE-----
Tanner Burson
That has got to be one of the best analogies I've read in a long, long time
Martin DeMello
Agreed! Though there goes our "come on, it's not exactly rocket science"
argument :)
martin
Gene Tani
subclass the class with the private methods, and declare the
superclass' private method public in the subclass.
David A. Black
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.