From: Intransition Date: 2010-11-04T20:24:14+09:00 Subject: Re: the dark side of inherited methods On Nov 4, 4:47 am, Robert Klemme wrote: > I am not sure I get your point.  What do you mean by access to > Numeric.new?  Method new is defined in Class and Numeric does not have > a method #initialize: That is what I am referring. > irb(main):029:0> Numeric.ancestors.map {|cl| > cl.instance_method(:initialize) rescue cl} > => [#, Comparable, > #, Kernel, > #] > > Did you mean Integer?  I describe the issue herehttp://blog.rubybestpractices.com/posts/rklemme/019-Complete_Numeric_... No not Integer, although this holds for it too. Your HexNum is a perfect example. Notice you never use #super in it's implementation. Because you can't. Also try calling a Numeric method that you haven't defined for HexNum, like #ceil. > Even that would only be a case of a specific class and not something > about inheritance in Ruby in general. > > What is it that you find "poor" about inheritance in Ruby? There are different things. For one I don't think the core classes are well honed for inheritance, hence the original topic of this thread. > >> > The other day I was talking to my Father, a Cobol programmer from back > >> > in the day, and he was telling me that when he retired, OOP was just > >> > starting to get hyped. He was quite interested in it at the time and > >> > then rattled off some of the advantages he remembered it was to bring > >> > to the field. Inheritance for code reuse was high on the list and > > >> Well, there are other forms of code reuse - even in procedural > >> languages.  It's not that you _need_ inheritance to have code reuse.  I > >> would even go as far as to claim that it is more difficult to implement > >> classes intended solely for implementation inheritance than classes > >> which implement a particular real world concept and which are only > >> inherited if "is a" is needed.  I say this because a class intended for > >> implementation inheritance needs other criteria for including > >> functionality than a class which implements a particular concept. > > > I think implementation inheritance becomes easier if classes are kept > > small with simple APIs and focused on a limited goal. Then larger > > "real world" classes are built up by inheriting from these smaller > > abstractions. > > Makes me think of traits.  Scala has some nice features in that area IIRC. > > http://www.scala-lang.org/node/126 > > > But to have a really robust system to do this, one needs > > some tools that Ruby doesn't provide, such a private inheritance, > > probably class private instance variables and methods, and better > > multiple inheritance than Ruby's mixin system. > > Exactly. > > > I think there is a place for both inheritance and composition. It's > > not an all or nothing deal. I think Enumerable is actually a great > > example of the power of inheritance when used well. And I think Ruby > > would be even better if it took that idea and ran with it a bit > > further. > > What exactly would you like to have changed in the language?  So far I > always liked the simplicity and cleanness of Ruby.  But maybe > evolutions of the language are possible that will maintain the balance > yet get more out of inheritance.  I am really curios what you are > imagining. * Getting rid of class vs. module distinction. * Have #include (or another method) provide "class level" methods in inheritance chain. * Private inclusion, such that all methods of class/module being included are private to the including class/module. * (Maybe) class private methods and variables, i.e. methods not visible to the inheritance chain. * Built-in method to mean `self.class.new()` --I think people forget to do it that way. * Built-in support for parametric mixins. * Work on improving modularity of core library (e.g. Facet's Indexable and Hashery's Ostructable). I'm sure there are others too. And it's not an all or nothing deal. Any one of them would improve upon things. I agree about the simplicity. In fact, in some ways I want it to be even more so.