Sorry about the delay... you know how it is!

On Jun 25, 8:30 ¨Âí¬ Òïâåòô Ëìåííå ¼óèïòôãõô®®®Àçïïçìåíáéì®ãïí¾ ÷òïôåº
> I always thought the proper idiom was
>
> # lib/foo.rb
>
> class Foo
> ..
> end
>
> # optionally:
> require 'foo/baz'
>
> # lib/foo/baz.rb
>
> require 'foo'
>
> class Foo::Baz
> ..
> end

Not always feasible, especially if you are loading a whole directory
of "pluggable" files.  In which case you either bottom require of use
a separate file. I just as soon not have to worry about it either way
and if class and module where the same type of object then we wouldn't
have to.

> Alternative:
>
> # lib/foo.rb
>
> class Foo
> ..
> autoload :Baz, 'foo/baz'
> end

I do not ever use autoload, as much as I might like to. It has a known
bug --it will not use a customized require. I used a customized
require in my development environment, so it is useless to me. (and
really the one thing that pisses the most... but thats' another story)

> # lib/foo/baz.rb
> (as above)
>
> >> > 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.
>
> That's a strange answer to my question...
>
> Let my first try to understand what you mean.  ¨Âçåùïðòïðåòìù ùï÷áîô
>
> module A
> def self.wok
> puts "I work for the class"
> end
>
> def foo
> puts "happy instance"
> self.class.wok
> end
> end
>
> class X
> include A
> end
>
> X.new.foo ->
> "happy instance"
> "I work for the class"
>
> I personally would write
>
> def foo
> puts "happy instance"
> A.wok
> end
>
> and be done so I suspect you mean something else.

Well that's one thing. But look what happens:

  class Y < X
    def self.wok
      "ain't going to happen"
    end
  end

You've strapped the implementation to a specific module, so there is
no way to override behavior in a subclass (short of overriding every
method that uses #wok).

> > 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?  ¨Âáùâå ôèåòéó óïíå òåáóïî ïî> > can find, but even so it seems to me that it must be the rarity.
>
> If I get your drift you want to use a single module to define a DSL
> and apply it at the same time, e.g.
>
> module DSL
> def self.smart_attribute(sym)
> class_eval "def #{sym}; puts 'Look Ma, how smart I am!'; @#{sym};nd"
> end
>
> smart_attribute :name
> end
>
> and then
>
> class Foo
> include DSL
>
> smart_attribute :age
> end
>
> f = Foo.new
> f.name
> f.age
>
> I personally would separate the DSL out into another module because
> that is more modular.  ¨Âïô áìãìáóóåíéçèîååä óíáòáôôòéâõô> "name" so this would be a better choice IMHO.

Well, you could do that. But that's not really the main issue.
Probably the most significant issue is with super:

  module M
    def self.x; "M"; end
  end

  class X
    include M
    def self.x
      super
    end
  end

You get an error. If it wasn't for this class inheritable attributes
would be completely trivial to implement.

Another more clear case is where the DSL defines a method that uses
another method the instance level as an overridable piece of
functionality.

  module DSL
    def self.smart_attribute(sym)
      class_eval "def #{sym}; puts message + ' ' + @#{sym}.to_s; end"
    end

    # Default message is 'Look Ma, a smart:'.
    def message
      'Look Ma, a smart:'
    end
  end

Not being able to do this, you have to do more difficult meta-
programming tricks to achieve the same result.

> > 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:
>
> >  ¨Âïäõì> >  ¨Âåæ óåìæ®áððåîäßæåáôõòåó¨âáóå©
> >  ¨Âáóå®åøôåîä óåìæ
> >  ¨Âîä
> >  ¨Âîä
>
> > Of course, rather than fuss about it, we could also have the best of
> > both worlds (imagine that).  ¨Âæïïîå¬ ÷ïõìâå èáðð÷éôè îå> > method to go along with #include and #extend that provided both
> > singleton and instance levels.
>
> I believe automatically propagating class methods might cause
> confusion because it is not obvious. At least I haven't had the need
> for this (which might be due to the different tasks we tackle with
> Ruby).

To me, not propagating them is "not obvious" --anything that creates
more work for me, when the alternative has no significant issues,
seems "not obvious" ;)

> >> > 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.

> I believe this points into the right direction.  ¨Â§í îïäïéîáó íõãè
> meta programming - probably because I am not involved in creating
> frameworks in Ruby.  ¨Â òáôèåò õóôèìáîçõáçå ôï óïìöäáôï äá> problems.  ¨Âæáíù îååä æïÄÓ̧èáâååî óãáòãå ¨Â÷èåò÷åòå
> you really hurt by not automatically propagating class methods?  ¨Â
> can't think of a case but obviously you have one in mind.

Look at Anise, look at Facets Inheritor. And wherever you find the
ClassMethods hack, that is a case, and there are many of those around.