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?
Vote for this RCR
Add comments here
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..
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.
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.
Back to RCRchive.
RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog
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..