Achieve pure object oriented design in Ruby

I hope that wasn’t me. I am opiniated, but I never intended to be rude.

Could not agree more with you.
Could not disagree more with the rest of the post, but that is
fortunately
our right of free speach.

Cheers
Robert

5r1WNNWlgIjpsmZD7kp2RM2wq4Hj6Ic/TqKrMpUIcdHF4TssV3tgqhSPB4CMTj5j
Xy5A0KI7996mIsTgKyreFYEtp8ewOkBKZPBy+UgwB4tnjjzyhcEN/XrMS+C7f+UM
cC0kcTK1I4aOix970KI32+HKHIDdbl9zE9sHXmPYc+kqYQRcZ3QuXNFS8NE4901R
JuyqdUwC9aZrpSjl/ohwwreRdEvFOArSpd/vWhpFKqX6XbLJgVdNZEhiLEjaOuSO
qSIdRLszxILf2r2tCIP6piDL92eOKv7+r37xE/jkP8Mc5aP+D8JjBA==
=vtUr
-----END PGP SIGNATURE-----


Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

  • Albert Einstein

On Wed, Jun 21, 2006 at 08:19:15PM +0900, Robert D. wrote:

On 6/21/06, Juergen S. [email protected] wrote:

In no language private/protected (or final) is a fool proof security

I doubt this strongly, Ada springs into mind.

Disassemblers/source extractors. Debuggers. Special kernel
modules. Running in a VM with outside tracing mechanisms
attached. Need I continue? This may take the attacker to an
outside-the-language level, but is still very practical.

The best feature of Ada is probably its obscurity outside some special
user groups.

measure. It is there to provide some safety nets against errors, and

to help design, not for security. It is quite easy in C++ to get at
any function in memory via pointers. In Java people can use AOP to
accomplish this.

In theory I hate it, in practice it is frequently sufficent.
Ruby is not doing that bad either, in practice I will often not care if
somebody redefines the access rights of my methods, I feel that this is a
theoretical discussion, though, right ?

Yes. But practical work is not far behind, and it usually suffices if
one of your users breaks your defenses and distributes a “crack”
around. You sit on the wrong side of a long lever here, hence my
advice to not waste effort in a lost battle.

Your most economical bet is to just document the class (or whatever)

to be “private, not to be used directly” in Ruby. Sometimes the
low-tech effort is simply the best, especially if any high-tech effort
is going to put you to much more troubles than the attacker, who will
circumvent it fast any way.

I appreciate your defence of ruby :wink: but the ability to completely hide
implementation from the interface user is a feature not a bug.

Most people who would consider this a feature would also consider
static typing a feature – ruby is different. It is a feature of ruby
to be dynamic and reflective. Don’t misunderstand me, I am all for
encapsulation, but as a design not a security/obscurity device.

I dare you to show me a system that manages to completely hide away,
apart from secure hardware (like smartcards).

It does not seem a good idea to me to allow everything with the perfect
excuse of following the “enabeling approach”, because it does not allow me
to implement some of the more basic principles of modern Software Design
(Data Hiding for instance).

Encapsulation <> data hiding, and the former counts IMHO. I’d contend
that hiding in your sense is a basic software design principle, that
is a not so uncommon misunderstanding about OOP.

All this is on a philosophical base, in practice Ruby gives me what I need
However, I is not the world, as has been pointed out to me frequently and
recently, quite a rude message BTW :wink:

Cheers
Robert

I hope that wasn’t me. I am opiniated, but I never intended to be rude.

-Jürgen

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs