gwtmp01 / mac.com schrieb:
>
> 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
>
>


I agree...

I think it's kind of old fashioned to hide all and everything from 
hostile coders doing development in your team (sounds strange anyway...)

My experience is that hiding stuff causes problems when you try to 
extend existing object / classes. You then have to break everything just
to get your thing going. Even the best gurus oversee possible uses of 
their libraries...

Hiding methods, etc. never in my career saved me from doing the wrong 
thing. The only thing that does is good documentation (rare thing!) 
and talkative names...