Differencies in module functions?

[??????]

Hey there,

Recently I was looking over some different ways of defining 'the same junk' within a module, example below;

module MyFunkyModule def the_same_junk # do junk end module_function :the_same_junk def self.the_same_junk # do junk end class << self def the_same_junk # do junk end endendObviously, there is some visual difference to the way the code is written, but what else?  Are there actually subtle differences in what its doing to the module its defined in ??

 

[Lemur]

That I'm aware of, no, but it's bad form to put a bunch of static methods on a module if it's not something of a library of functions like Math and friends.

Normally the second form is preferred as it's very explicit about what it is up front. The third form can lead to confusion from a cursory read and the first form only tells you it's a module method after definition.

To be fair in Ruby 2.x you could have done this:

module_function def the_same_junk  # do junkend

They return their names on definition in later versions of ruby.

 

[Another Fen]

As far as I'm aware there is a difference in where the interpreter looks for the definition of constants:

1) and 2) : MyFunkyModule, then ancestors of MyFunkyModule

3) : Metaclass of MyFunkyModule, MyFunkyModule (you nested the definition within), then ancestors of the Metaclass.

I'm not entirely sure about this order...

Edit: Implied a bit much

 

[cremnophobia]

A module function is a (private) instance method and a copy of it as a singleton method. So only 1 qualifies for that. 2 and 3 are basically the same (only define a singleton method). Of course, there are some differences, but they don't matter in this case.

 

[??????]

To be fair in Ruby 2.x you could have done this:

module_function def the_same_junk # do junkendThey return their names on definition in later versions of ruby.

For some reason I really dislike the syntax of that :/

I would much prefer doing something like the below example, assuming it was possible of course ~ I haven't played much with ruby 2.x :/

def module_function the_same_junk  # stuffendAnyway, for some reason this example s more appealing to my eyes ^_^

3) : Metaclass of MyFunkyModule, MyFunkyModule (you nested the definition within), then ancestors of the Metaclass.

So, what is the difference between the MyFunkyModule metaclass and the actual MyFunkyModule module itself?

@cremno - That certainly helps to clarify a little.

Could you please elaborate on the differences?  I know there would be differences when mixing in the module, or even calling a function from it from outwith the module, but are there still things its doing differently when only ever used from within the module itself?

 

[Another Fen]

Maybe "Singleton Class" would have been a more fitting term than "Metaclass".

MyFunkyModule is an instance of the class Class, but you can define unique behavior for it by accessing its singleton class, which behaves like an exclusive subclass (as you did by using  class << self).

As for the difference:

Spoiler

class Test  TESTCONST = selfendclass << Test  TESTCONST = selfendclass Class TESTCONST = selfend# -----------------class Test   def self.one    TESTCONST  end   class << self    def two      TESTCONST    end  endenddef Test.three  TESTCONSTend# -----------------p Test.one   # => Testp Test.two   # => #<Class:Test>p Test.three # => #<Class:Test>class << Test  remove_constTESTCONST)endp Test.one   # => Testp Test.two   # => Testp Test.three # => Classclass Test remove_constTESTCONST)endp Test.one   # uninitialized constant Test::TESTCONSTp Test.two   # => Classp Test.three # => Class

It probably won't matter in most cases though.

You can use  module_function  like the  private/public modifiers to create module functions from multiple subsequently defined instance methods without having to type self.... every time. As a method prefix I don't really like it yet either.

The problem with

def module_function the_same_junk
  # stuff
end

is of course that module_function can be interpreted as the methods name unless you make it a keyword.