[LRUG] Global methods vs. Kernel mixins

[Rob Miller]

Thanks, that clears some things up — but I'm still left with the question of why you'd do that rather than just defining a global method? Seems an unnecessary hoop to jump through. 

Rob

On 18 Jul 2013, at 08:33, Tejas Dinkar <tejas at c42.in> wrote:

> On Jul-18-2013, at 12:39 AM, Rob Miller <rob at bigfish.co.uk> wrote:
>> I'm wrong!), and I understand the implications of adding a private method to Kernel (it can only be called as Kernel.foo or totally unprefixed, it doesn't show up as a method on all objects?).
>> 
> Actually, the private method cannot be called as Kernel.foo. That would be a self method on kernel. In ruby, private only means that the method has to be called with an implicit receiver.
>> Surely both ways end up with a global method that's callable from everywhere? Why jump through the hoop of mixing-in to Kernel? Are there any advantages?
>> 
> Technically not entirely true (that they are global, accessible from everywhere).
> 
> Just defining a method will define the method on Object. So in most cases, it should behave similarly, since Object mixes in Kernel.
> 
> There are some objects like BasicObject, which does not mix in Kernel.
>> Is this some scope-related problem, linked to the fact that he defines a module called Main also (so he couldn't defined a method with the same name)?
>> 
> 
> Not really. Ruby actually lets you define a method with the same name as a constant.
> 
> class Foo
> end
> 
> def Foo
> end
> 
> Foo => This returns the class
> Foo() => This returns nil
> --
> Tejas Dinkar
> http://www.nilenso.com
> Nilenso Software (formerly the consulting arm of C42 Engineering)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130718/86030df7/attachment.html>