Hi --

On Sun, 15 Jun 2008, Greg Hauptmann wrote:

> On Sun, Jun 15, 2008 at 11:29 PM, Robert Klemme <shortcutter / googlemail.com>
> wrote:
>
>> On 15.06.2008 15:17, Greg Hauptmann wrote:
>>
>>> Thanks - can I ask:
>>>
>>
>> Guess so.
>>
>>  (a) what do you mean by "explicit" - just to understand
>>>
>>
>> no_explicit_receiver()
>> self.has_explicit_receiver()
>>
>>  (b) is there a way I can adjust my code so that I can leave methods like
>>> "reconcile_one" private or protected, i.e. not really to be available to
>>> the
>>> outside world (except in this case where I'm calling it from with an
>>> instance of the class really, but it's just the logistics of Ruby that
>>> isn't
>>> allowing it to work...if I've understood things correctly)
>>>
>>
>> You can use #send or #instance_eval, e.g.
>>
>> irb(main):001:0> class F
>> irb(main):002:1> protected
>> irb(main):003:1> def x;1 end
>> irb(main):004:1> end
>> => nil
>> irb(main):005:0> f=F.new
>> => #<F:0x7ff94460>
>> irb(main):006:0> f.x
>> NoMethodError: protected method `x' called for #<F:0x7ff94460>
>>        from (irb):6
>>        from :0
>> irb(main):007:0> f.instance_eval { x }
>> => 1
>> irb(main):008:0> f.send :x
>> => 1
>> irb(main):009:0>
>>
>> Cheers
>>
>>        robert
>>
>
> Thanks Robert - do you understand why Ruby allows the "send :x" method to
> work here, but not the ".x" out of curiosity?  Does this make sense to
> people it should do this?

Private and protected are really only advisory, since you can in fact
always get around them. The idea is to have the most common
method-calling technique (the dot) respect them, so that if you want
to get around them, you have to make a point of using one of the other
techniques.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS   June 16-19           Berlin
   ADVANCING WITH RAILS   July 21-24           Edison, NJ
See http://www.rubypal.com for details and updates!