Comments on: Modules Part I - Enter the Include Class http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/ Ruby and otherwise by Patrick Farley Wed, 08 Sep 2010 21:07:27 +0000 http://wordpress.org/?v=2.2.3 By: Daniel Berger http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-231 Daniel Berger Mon, 17 Dec 2007 19:55:06 +0000 http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-231 Along the same lines, what are your thoughts on selector namespaces? They could be added in Ruby to allow the user to select the inheritence hierarchy, couldn't they? I wrote a post about them a while back if you're interested: http://djberg96.livejournal.com/50830.html Along the same lines, what are your thoughts on selector namespaces? They could be added in Ruby to allow the user to select the inheritence hierarchy, couldn’t they?

I wrote a post about them a while back if you’re interested:

http://djberg96.livejournal.com/50830.html

]]> By: Daniel Berger http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-230 Daniel Berger Mon, 17 Dec 2007 19:29:28 +0000 http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-230 Oh, no. We're not headed towards a discussion on Traits, are we? ;) BTW, minor typo. You've got a double "is" at "This reference to the actual module is is useful for the case" Oh, no. We’re not headed towards a discussion on Traits, are we? ;)

BTW, minor typo. You’ve got a double “is” at “This reference to the actual module is is useful for the case”

]]> By: pfarley http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-177 pfarley Mon, 26 Nov 2007 12:43:56 +0000 http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-177 Hi Bill, You are correct in assuming that method dispatch will find the method it's looking for in the last module mixed in. There is no name collision problem as the methods are not stored in the same place, they are keys on different m_tbls. Since the method is found in the m_tbl of the latter module, the interpreter does not follow the super chain to check the m_tbl of the first module. This behavior is more or less identical to an overridden instance method in a subclass. One of the things I'm hoping to get across in this and the following post is that mixins, positive press notwithstanding, are a form of inheritance, albeit a very dynamic one. That means that they are prey to some of the problems of deep and complex inheritance structures. Thanks for the comment and for reading. Hi Bill,

You are correct in assuming that method dispatch will find the method it’s looking for in the last module mixed in. There is no name collision problem as the methods are not stored in the same place, they are keys on different m_tbls. Since the method is found in the m_tbl of the latter module, the interpreter does not follow the super chain to check the m_tbl of the first module.

This behavior is more or less identical to an overridden instance method in a subclass. One of the things I’m hoping to get across in this and the following post is that mixins, positive press notwithstanding, are a form of inheritance, albeit a very dynamic one. That means that they are prey to some of the problems of deep and complex inheritance structures.

Thanks for the comment and for reading.

]]> By: Bill Six http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-176 Bill Six Mon, 26 Nov 2007 07:06:38 +0000 http://www.klankboomklang.com/2007/11/25/modules-part-i-enter-the-include-class/#comment-176 I'm relatively new to Ruby, so sorry if this question is trivial. What happens if two modules both provide a definition for method with the same name? Since they are mixed-in in a linear order, I would assume that the first one found is invoked. I would also assume that, if this were a problem, the methods in each mixin would be prefixed by something unique (like the module name) to avoid the method-name clash. If my understanding of mixins is correct; do people find this a problem in practice? I’m relatively new to Ruby, so sorry if this question is trivial.

What happens if two modules both provide a definition for method with the same name? Since they are mixed-in in a linear order, I would assume that the first one found is invoked. I would also assume that, if this were a problem, the methods in each mixin would be prefixed by something unique (like the module name) to avoid the method-name clash.

If my understanding of mixins is correct; do people find this a problem in practice?

]]>