ruby picture

RCR 173: Advanced Feature Visibility

Submitted by minam (Tue Dec 02 03:12:24 UTC 2003)

Abstract

This is a legacy RCR from Ruby Garden, submitted by minam. Matz has declared these RCRs obsolete, and asked that their authors resubmit them in the new format.

I've already written up a more formal RCR for this, at > arden.org/ruby?AdvancedFeatureVisibility. A quick summary for those of you that don't want to click the link and read it, though:

Ruby currently supports only "public" and "private" visibility, and the "private" visibility is really more like "protected." Eiffel, on the other hand, supports a very robust version of feature visibility, which is actually a superset of what Ruby supports. I propose that a modified version of Eiffel's feature visibility mechanism be implemented for Rite.

Please read the RCR at the given link for more info, and an example of what exactly this all means. Comments, please?

Problem

(RCR imported from old format)

Proposal

Analysis

(RCR imported from old format)

Implementation

(RCR imported from old format)
ruby picture
Comments Current voting

this is cool, but maybe as a module (, 2003-12-06 11:26:07)

I suggest that this may live happily as an add on module.
Ruby is quite 'liberal' in the access control. You may still get acces to a var via reflection, so introducing a safe syntax like this still does'nt gain you the security you may expect from eiffel.

BTW, having this as a pluggable module still makes this a powerful feature to include in your code, if you feel the need for it..

concur, a good module (transami, 2003-12-07 16:57:11)

I tend to agree with the last comment. I do not think this should be built into Ruby "out of the box".

But, I do think, that if you keep fine tuning this as a module so it works really well, it would certainly make a fine add-on library to include in the Ruby distribution.

Problem with using this as module (minam, 2003-12-07 20:29:57)

The problem with using this as a module (at least as Ruby is right now) is that it gives very (very!) limited call-stack access, which makes determining the caller of a method very fragile.

I agree that reflection in Ruby can bypass any sort of protection, but that's not really the point. All I want is to make it difficult for people to access my methods, to encourage the use of my published, "public" API. Also, since this is really a superset of Ruby's existing access control, it shouldn't change anything at all as far as those developers who don't want it are concerned.

I could live with doing this as a module, though, as long as the call-stack becomes more robustly accessible.


Strongly opposed 0
Opposed 0
Neutral 0
In favor 0
Strongly advocate 0
ruby picture
If you have registered at RCRchive, you may now sign in below. If you have not registered, you may sign up for a username and password. Registering enables you to submit new RCRs, and vote and leave comments on existing RCRs.
Your username:
Your password:

ruby picture

Powered by .