On Jun 24, 11:58 ¨Âí¬ Òïâåòô Ëìåííå ¼óèïòôãõô®®®Àçïïçìåíáéì®ãïí¾ ÷òïôåº

> I don't understand what you mean here.  ¨Âáî ùïåìáâïòáôïò ðòïöéäáîøáíðìå

# lib/foo/baz.rb

class Foo::Baz
  ...
end


# lib/foo.rb

require 'foo/baz'

class Foo
  ...
end


> > 2) The developer is forced to choose between two arbitrarily limited
> > mechanisms for modeling behavior. Classes can only re-used once per
> > subclass and not at all via modules. Modules can be reused extensively
> > but do not naturally include their singleton methods. These
> > limitations lead to a number of code smells from overly limited use of
> > inheritance to included/ClassMethods hooks.
>
> Why is not including their singleton methods a strong limitation?

Well it is strong. In fact, if it wasn't for that, the difference be
almost ephemeral. But strong != good. I know that matz has cited this
issue in the past, but I have never seen an explanation of why it is
so bad to get the module singleton methods? Clearly in many cases that
is exactly what people want, which is why they ClassMethods hack is so
common. If it were the other way around, and the singleton methods
were passed along, but you didn't want them to be... well I would like
to know under what circumstances that it would really be a problem. If
those singleton methods were simply being used as functions (M.f) then
they can easily be placed in a separate module. If they were being
used as a DSL for the module itself, why would the including class be
any worse off by gaining the DSL too?  Maybe there is some reason one
can find, but even so it seems to me that it must be the rarity. In
all my use of modules I can't think of case where having the singleton
level would have been a problem and in many, if not most, I actually
wanted it and had to resort to some hoop jumping.

In fact, and I think this is worth pointing out... I never ever design
a module to be utilized via #extend. In such usecases I actually do
this:

  module M
    def self.append_features(base)
      base.extend self
    end
  end

Of course, rather than fuss about it, we could also have the best of
both worlds (imagine that).  I, for one, would be happy with a new
method to go along with #include and #extend that provided both
singleton and instance levels.

> > 3) Using tools for conceptually different cases does not require that
> > their be physically different tools for each case. I wrench is just as
> > good for tightening a nut as it is for loosening one. If I had to use
> > two separate tools it would be quite annoying.
>
> I believe this is a bad analogy.  ¨Âáô áìùï÷ïõìèáöå ôï ôáëå
> "tightening and loosing nuts" and "hammering".  ¨Âôèáô ãáóå éô§ó
> quite obvious that you would not normally use the same tool for the
> job.

Maybe so. But a class is a subclass of module. So they are very
similar tools, unlike a hammer and a wrench. My point was simply that,
as craftsman, we'd rather have just one tool, if it can do the job two
just as well.

> > Following your conceptual distinction argument we could just as easily
> > argue for separate entities for mixins and namespaces  ¨Âéîãå ôèïóáò> > also different uses of modules. Clearly no one wants that.
>
> Actually I thought about mentioning this because namespacing is yet
> another concept which happens to have two tools - module and class.
> It probably feels very natural because all major OO languages do
> support this.  ¨Âîä éô äïåó èáöå óïíå íåòéôó>
> > I have never heard of a solid reason for the division between classes
> > and modules --my guess is that there is no real reason other than that
> > it how it was done originally, and changing it now means 1) a major
> > version bump and 2) an overhaul of the implementation.
>
> I find that distinction pretty clear as I have tried to point out
> earlier.  ¨Âïíåèï÷ ùïóååí ôï âå õóéîôèìáîçõáçå ñõéôäéææåòåîôì> than me and have run into limitations that do not exist for me.  ¨Âáùâå
> we can take the discussion a bit further to find out more about this.

Perhaps b/c I have done a lot of meta-programming? Not sure. It would
be interesting to know more, I agree.

> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/