2009/5/26 Simon Chiang <simon.a.chiang / gmail.com>:
> I sometimes use nested classes to avoid namespace clutter.  ¨Âèå ïîìù
> downsides I found are related to inheritance, in particular when you
> split out classes into different files.
>
>  ¨Âá®òâ>  ¨Âåñõéòå §á¯â>  ¨Âìáóó ÓõðåòÃìáóó
>  ¨Âîä
>
>  ¨Âá¯â®òâ>  ¨Âìáóó ÓõðåòÃìáóó
>  ¨Âìáóó >  ¨Âîä
>  ¨Âîä
>
> In both files you have to have the correct superclass (which can be
> hard during refactoring).  ¨Âèåòå áòäéææåòåî÷áùó ôï ãïîóôòõãôèéó> however:
>
>  ¨Âá®òâ>  ¨Âìáóó ÓõðåòÃìáóó
>  ¨Âåñõéòå §á¯â>  ¨Âîä
>
>  ¨Âá¯â®òâ>  ¨Âìáóó ÁººÂ
>  ¨Âîä
>
> The downside of this is that 'a/b.rb' can't be required on it's own.

IMHO this is not a problem of inheritance but of clear priority: class
A should be defined in one primary file.  All other files that
*modify* it (i.e. by adding method or whatnot) should require that
primary file and reopen the class to do whatever they need.

So, basically the layout should look like this:

[a.rb]
class A < SuperClass
  def method_of_A_which_does_not_use_B
  end
end

[a/b.rb]
require 'a'

class A
  class B
  end

  def method_of_A_which_uses_B
  end
end

Actually, if you use A only for namespace handling then a module would
probably a better thing to have here.  Other than that, if A's
implementation needs A::B to work, then splitting both out into two
files does not make much sense.

Kind regards

robert


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