From: gwtmp01@...
Date: 2006-06-22T06:19:49+09:00
Subject: Re: Achieve pure object oriented design in Ruby


On Jun 21, 2006, at 12:51 PM, Robert Dober wrote:
> On 6/21/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
>> On Jun 20, 2006, at 6:02 PM, Robert Dober wrote:
>> > The real problem is  requirement 2) of the OP,  instanciation of
>> > class B
>> > shall only be possible in class A, e.g. in an instance of A, I do
>> > not think
>> > this is possible, but I would not bet on it (not much).
>>
>> Why not just make B an anonymous class:
>>
>> class A
>>    def initialize
>>      @bclass = Class.new do
>>        # class definition here
>>      end
>>      @bs = []
>>    end
>>
>>    def another_b_please
>>       @bs << @bclass.new
>>       @bs.last
>>    end
>> end
>>
>>
>
>
> Gary that is what I did, and discussed above. ( I used an anonymous  
> class
> inside A, you use one inside an instance of A, which might be quite
> disturbing unless A is a singleton itself!!)
>
> One can create an accessor to @b at any time
>
> class A
>   attr_accessor :bclass
> end
> A.new.bclass.new  #voil�
>


Yeah, I shouldn't have written it as creating a new class for each  
instance of A.  Something like:

class A
   @bclass = Class.new {
     # anonymous class def here
   }
   # details left for the reader...
end

would be better.  Yes, you can always reopen A to create an accessor  
to @bclass but that is a general characteristic of any Ruby code.  I  
think tucking the reference to the class in an instance variable  
hides it a 'little' better than having the reference be a constant in  
A. A::B.new is pretty accessible as is changing the visibility of B.new.

Still, I'm not sure that it makes sense to go to all the trouble to  
'hide' these other classes.  Whenever I see this sort of thing I say  
'why bother?'.  The idea that you can programatically protect  
yourself against some hostile coder who can modify the *source* code  
(or link into your library in a static language) just seems like a  
waste of time. And the idea that you can enforce correct calls to  
your API in the absence of some appropriate documentation seems even  
more far fetched.  People don't just guess randomly at the arguments  
and sequence of calls to a class/library.  They are looking at  
examples or documentation.  If they want to experiment with calls  
that are undocumented or that explicitly violate a documented pre- 
condition of the API, why do I care?

If you really want to protect yourself against hostile client code, I  
think you have to go to an inter-process communication interface to  
your library/service.


Gary Wright