CSC/ECE 517 Fall 2007/wiki1 1 as: Difference between revisions
(/* Question 1: If multiple methods with the same name are defined, there needs to be some way of determining which method a call refers to. The general rule is given on p. 123 of Programming Ruby. But) |
No edit summary |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Question 1 | == Question 1: If multiple methods with the same name are defined, there needs to be some way of determining which method a call refers to. The general rule is given on p. 123 of Programming Ruby. But questions still remain. == | ||
'''I.) Is it possible to get unexpected behavior if one of the modules you are using is "enhanced" to contain a new method that happens to conflict with a name of an existing method?''' | '''I.) Is it possible to get unexpected behavior if one of the modules you are using is "enhanced" to contain a new method that happens to conflict with a name of an existing method?''' | ||
Line 14: | Line 15: | ||
Yes, by adding ‘require’ statements for the modules being used, and invoking the methods with the qualified name (ModuleName:method), conflict can be avoided. | Yes, by adding ‘require’ statements for the modules being used, and invoking the methods with the qualified name (ModuleName:method), conflict can be avoided. | ||
'' | |||
Source: http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html | ''Source: http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html'' | ||
Latest revision as of 19:39, 28 September 2007
Question 1: If multiple methods with the same name are defined, there needs to be some way of determining which method a call refers to. The general rule is given on p. 123 of Programming Ruby. But questions still remain.
I.) Is it possible to get unexpected behavior if one of the modules you are using is "enhanced" to contain a new method that happens to conflict with a name of an existing method?
Yes, it is possible to get unexpected behavior if the user does not use the qualified name when calling the ambiguous method. Ruby will first search the last module included, and continue in a descending order. The method that is invoked may not be the method that the caller expected to run.
Source: Programming Ruby textbook
II.) Is it possible to refer to these methods using a qualified name?
Yes, by adding ‘require’ statements for the modules being used, and invoking the methods with the qualified name (ModuleName:method), conflict can be avoided.
Source: http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html
III.) Is it possible to use method aliasing to resolve the ambiguity?
Yes, a library is available to allow a class to selectively mixin methods from a module, as opposed to all of the module’s methods, and alias them on the fly to avoid conflicts.
Source: http://rubyforge.org/docman/view.php/735/309/readme.html
IV.) What approach does good o-o design dictate?
Calling the modules’ methods using qualified names is the better OO design approach. With the alias approach, the inheritance is limited and the programmer will need constantly update the list of aliases for methods needed as they come up.
However, inheriting from the entire module and using the qualified names to avoid conflicts is a more efficient OO approach. It is also easier to read and maintain because in viewing the call, a reader will immediately gather the expected behavior of the call, as opposed to finding the alias definition and trying to make the connection.