Editing Topic: RCR173 Project: RCR | RCRchive home

RCR 173: Advanced Feature Visibility

submitted by minam on 2003-12-01 22:53:24

This is a legacy RCR. If this is your RCR, please resubmit it using the new format and process.

I've already written up a more formal RCR for this, at . 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?

----
=== Add comments here
<h4 class="commentheader">this is cool, but maybe as a module (, 2003-12-06 11:26:07)</h4>
<div class="commentbody">I suggest that this may live happily as an add on module. <br />
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.<br />
<br />
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.. </div>
<h4 class="commentheader">concur, a good module (transami, 2003-12-07 16:57:11)</h4>
<div class="commentbody"><p>I tend to agree with the last comment. I do not think this should be built into Ruby "out of the box".

<p>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.

</div>
<h4 class="commentheader">Problem with using this as module (minam, 2003-12-07 20:29:57)</h4>
<div class="commentbody">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.<br />
<br />
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.<br />
<br />
I could live with doing this as a module, though, as long as the call-stack becomes more robustly accessible.</div>

Back to RCRchive.

RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog