Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-13T03:28:49Z

Arjones3: /* 2. Using Namespaces to Avoid Conflict */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when a call is made to a method with an ambiguous name.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because Ruby will first search the last module included, and continue in a descending order until it finds a method with that name. Since in this case, Test was the last module included, its method was the one invoked. The method that is invoked may not be the method that the caller expected to run. Therefore, precaution should be taken to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method named bar, and makes a call to both bar methods in Foo and Test. However, if the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using aliases

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-13T03:26:56Z

Arjones3: /* 1. Method Name Conflict */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when a call is made to a method with an ambiguous name.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because Ruby will first search the last module included, and continue in a descending order until it finds a method with that name. Since in this case, Test was the last module included, its method was the one invoked. The method that is invoked may not be the method that the caller expected to run. Therefore, precaution should be taken to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using aliases

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-13T03:25:50Z

Arjones3: /* 1. Method Name Conflict */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when a call is made to a method with an ambiguous name.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because Ruby will first search the last module included, and continue in a descending order until it finds a method with that name. Since in this case, Test was the last module included, its method was the one invoked. The method that is invoked may not be the method that the caller expected to run. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using aliases

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-13T03:24:12Z

Arjones3: /* Background */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when a call is made to a method with an ambiguous name.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using aliases

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-13T03:22:57Z

Arjones3: /* Background */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using aliases

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:47:50Z

Arjones3: /* Conclusion */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using aliases

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:47:07Z

Arjones3: /* References */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164209 Class and Mixin with same name method problem]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:45:43Z

Arjones3: /* References */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Programming Ruby]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:44:07Z

Arjones3: /* References */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:43:56Z

Arjones3: /* Conclusion */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

With namespaces, the class controls what module will be invoked. However, with aliases, the caller controls what will be invoked. These two approaches have their advantages and disadvantages.

An advantage of using namespaces is that the logic that the programmer envisions is captured in the code. For example, the programmer may only be interested in Foo's bar method and not Test's bar method. This can be controlled by internally making the call to Foo.bar anytime the class's bar method is invoked. By the same token, this causes less flexibility, which is a disadvantage.

When using aliases, the caller is more in control. The caller can leverage the fact that the class it is calling has access to the bar method of two different modules, thus providing more power and flexibility. However, the disadvantage of this is that the caller must know the internals of the class it is calling. It must know which aliased method calls what module, and also what that module's method does.

In our opinion, using namespaces is the more efficient object-oriented (OO) design approach. Encapsulation is an important OO concept, and taxing the caller to research the internals of the code, while powerful, is inefficient.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://rubyforge.org/docman/view.php/735/309/readme.html 'use' package readme]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:30:49Z

Arjones3: /* 2. Using Namespaces to Avoid Conflict */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end
z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

In our opinion, using namespaces is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://rubyforge.org/docman/view.php/735/309/readme.html 'use' package readme]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:30:08Z

Arjones3: /* 3. Using Aliases to Avoid Conflict */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end

z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

The result of this call is:
hello
goodbye

Note: A call to z.bar would react the same way as shown in example one, with the result being a call to the last module included.

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

In our opinion, using namespaces is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://rubyforge.org/docman/view.php/735/309/readme.html 'use' package readme]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:27:51Z

Arjones3: /* 3. Using Aliases to Avoid Conflict */

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes. Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==
Using namespaces within the modules will make the method names unique and help disambiguate any conflicts. The namespace is created simply by prefixing the method name with the module name and a period (i.e., Module.method).

Let's modify the previous example to include namespaces.

module Foo
def Foo.bar #the method name is qualified
"hello"
end
end
module Test
def Test.bar #the method name is qualified
"goodbye"
end
end
class Zap
include Foo
include Test

Zap class defines a method called bar, and makes a call to both bar methods in Foo and Test. If the programmer knew for sure that any call to the bar method should invoke only one of the modules, this could be handled here by only calling the module of choice.
def bar
puts Foo.bar
puts Test.bar
end

z = Zap.new
puts z.bar

This will produce:
Hello
Goodbye

== 3. Using Aliases to Avoid Conflict ==
An alternative to using namespaces is to use alias to disambiguate method names in different modules. Again, looking at the first example, we have modified it to show the use of aliases.

module Foo
def bar
"hello"
end
end

module Test
def bar
"goodbye"
end
end

In the Zap class, we define two aliases, one for Foo's bar method and another for Test's bar method. The alias syntax is ''alias :new_name :old_name''. So, to disambiguate, we first include Foo, and give an alias to its bar method. Then include Test and give an alias to its bar method.
class Zap
include Foo
alias :Foo_bar :bar
include Test
alias :Test_bar :bar
end

The caller then can make a call to the new method names defined by the aliases to choose exactly which call they want to make.
z = Zap.new
puts z.Foo_bar
puts z.Test_bar

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

In our opinion, using namespaces is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]
#[http://rubyforge.org/docman/view.php/735/309/readme.html 'use' package readme]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:15:08Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:13:59Z

Arjones3: /* 2. Using Namespaces to Avoid Conflict */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T20:13:07Z

Arjones3: /* 2. Using Namespaces to Avoid Conflict */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:41:08Z

Arjones3:

__TOC__

= Background =

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes.

Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

= Examples =

== 1. Method Name Conflict ==

In the following example, we have the class Zap. This class includes the module Foo and the module Test. Both modules contain a method named bar.
module Foo
def bar
"hello"
end
end
module Test
def bar
"goodbye"
end
end
class Zap
include Foo
include Test
end

If a call is made to Zap's bar method, the caller is unsure whether the result will be "hello" or "goodbye".
z = Zap.new
puts z.bar

The result of this call is:

goodbye

This is because 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. Therefore, precaution to be taken within the class to eliminate ambiguity.

== 2. Using Namespaces to Avoid Conflict ==

module Grouchy
def Grouchy.say_hello(string='somebody')
puts "#{string} says: Don't tell me what to do!"
end
end

Grouchy.say_hello is the class method of the module Grouchy
We have a class Person which includes the module Grouchy

class Person

require "grouchy"

attr_accessor :name

def initialize(name='somebody')
@name = name
end

end
person = Person.new('Charlie')
Grouchy.say_hello(person.name)

It products:

Charlie says: Don't tell me what to do!

When facing the name conflicts problem, we can use namespace to tell the different of two methods.

module Debug
def Debug.who_am_i
"Debug"
end
end

module Burp
def Burp.who_am_i
"Burp"
end
end

class EightTrack
include Debug
include Burp
def who_am_i
puts Burp.who_am_i
puts Debug.who_am_i
end
end

et = EightTrack.new

et.who_am_i

It products:

Burp
Debug

Another way is using the alias method, we still have two modules have the same name method who_am_i.
module Debug
def who_am_i
"Debug"
end
end

module Burp
def who_am_i
"Burp"
end
end

class RubyTest
include Burp
alias :Burp_who_am_i :who_am_i
include Debug
alias :Debug_who_am_i :who_am_i
end

rt = RubyTest.new
puts rt.Debug_who_am_i
puts rt.Burp_who_am_i

== 3. Using Aliases to Avoid Conflict ==

= Conclusion =

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#using namespaces
#using an alias

In our opinion, using namespaces is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

= References =

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:32:56Z

Arjones3: /* 1. Method Name Conflict */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:31:23Z

Arjones3: /* 2. Using Namespaces to Avoid Conflict */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:23:06Z

Arjones3: /* 1. Using Namespaces */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:21:01Z

Arjones3: /* Conclusion */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:19:42Z

Arjones3:

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:17:52Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:17:36Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:16:40Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:15:19Z

Arjones3: /* 1. Using Namespaces */

__TOC__

== Background ==

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes.

Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

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.

== Examples ==

= 1. Using Namespaces =

module Grouchy
def Grouchy.say_hello(string='somebody')
puts "#{string} says: Don't tell me what to do!"
end
end

Grouchy.say_hello is the class method of the module Grouchy
We have a class Person which includes the module Grouchy

class Person

require "grouchy"

attr_accessor :name

def initialize(name='somebody')
@name = name
end

end
person = Person.new('Charlie')
Grouchy.say_hello(person.name)

It products:

Charlie says: Don't tell me what to do!

When facing the name conflicts problem, we can use namespace to tell the different of two methods.

module Debug
def Debug.who_am_i
"Debug"
end
end

module Burp
def Burp.who_am_i
"Burp"
end
end

class EightTrack
include Debug
include Burp
def who_am_i
puts Burp.who_am_i
puts Debug.who_am_i
end
end

et = EightTrack.new

et.who_am_i

It products:

Burp
Debug

Another way is using the alias method, we still have two modules have the same name method who_am_i.
module Debug
def who_am_i
"Debug"
end
end

module Burp
def who_am_i
"Burp"
end
end

class RubyTest
include Burp
alias :Burp_who_am_i :who_am_i
include Debug
alias :Debug_who_am_i :who_am_i
end

rt = RubyTest.new
puts rt.Debug_who_am_i
puts rt.Burp_who_am_i

== Conclusion ==

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#calling the module's methods using qualified names
#using an alias

In our opinion, the first approach, calling the module's methods using qualified names, is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

== References ==

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:12:59Z

Arjones3: /* Examples */

__TOC__

== Background ==

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes.

Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

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.

== Examples ==

== 1. Using Namespaces ==

module Grouchy
def Grouchy.say_hello(string='somebody')
puts "#{string} says: Don't tell me what to do!"
end
end

Grouchy.say_hello is the class method of the module Grouchy
We have a class Person which includes the module Grouchy

class Person

require "grouchy"

attr_accessor :name

def initialize(name='somebody')
@name = name
end

end
person = Person.new('Charlie')
Grouchy.say_hello(person.name)

It products:

Charlie says: Don't tell me what to do!

When facing the name conflicts problem, we can use namespace to tell the different of two methods.

module Debug
def Debug.who_am_i
"Debug"
end
end

module Burp
def Burp.who_am_i
"Burp"
end
end

class EightTrack
include Debug
include Burp
def who_am_i
puts Burp.who_am_i
puts Debug.who_am_i
end
end

et = EightTrack.new

et.who_am_i

It products:

Burp
Debug

Another way is using the alias method, we still have two modules have the same name method who_am_i.
module Debug
def who_am_i
"Debug"
end
end

module Burp
def who_am_i
"Burp"
end
end

class RubyTest
include Burp
alias :Burp_who_am_i :who_am_i
include Debug
alias :Debug_who_am_i :who_am_i
end

rt = RubyTest.new
puts rt.Debug_who_am_i
puts rt.Burp_who_am_i

== Conclusion ==

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#calling the module's methods using qualified names
#using an alias

In our opinion, the first approach, calling the module's methods using qualified names, is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

== References ==

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:07:32Z

Arjones3: /* Examples */

__TOC__

== Background ==

Ruby does not implement true multiple inheritance, but provides Modules as a way to reuse chunks of codes in many classes.

Modules, unlike like classes in OO languages such as Java, cannot be instantiated or sub-classed. Modules are included in class definitions by using the ‘include’ method which will mix that module’s methods into the calling class. The module’s methods will then become instance methods.

A class can include several modules within the class definition. However, a problem exists when a class includes multiple modules that contain a method of the same name. Since the class will have access to both of these methods, unexpected behavior may occur when the names of the methods conflict.

Let’s look at a few examples!

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.

== Examples ==

It’s the example of how to use namespace.

module Grouchy
def Grouchy.say_hello(string='somebody')
puts "#{string} says: Don't tell me what to do!"
end
end

Grouchy.say_hello is the class method of the module Grouchy
We have a class Person which includes the module Grouchy

class Person

require "grouchy"

attr_accessor :name

def initialize(name='somebody')
@name = name
end

end
person = Person.new('Charlie')
Grouchy.say_hello(person.name)

It products:

Charlie says: Don't tell me what to do!

When facing the name conflicts problem, we can use namespace to tell the different of two methods.

module Debug
def Debug.who_am_i
"Debug"
end
end

module Burp
def Burp.who_am_i
"Burp"
end
end

class EightTrack
include Debug
include Burp
def who_am_i
puts Burp.who_am_i
puts Debug.who_am_i
end
end

et = EightTrack.new

et.who_am_i

It products:

Burp
Debug

Another way is using the alias method, we still have two modules have the same name method who_am_i.
module Debug
def who_am_i
"Debug"
end
end

module Burp
def who_am_i
"Burp"
end
end

class RubyTest
include Burp
alias :Burp_who_am_i :who_am_i
include Debug
alias :Debug_who_am_i :who_am_i
end

rt = RubyTest.new
puts rt.Debug_who_am_i
puts rt.Burp_who_am_i

We alias the Burp’s who_am_i method to Burp_who_am_i and Debug’s who_am_i method to Debug_who_am_i so it products:

Debug
Burp

There is another way to do it. We can import a library, ‘use’ package.

module Foo
def bar
"hello"
end
def baz
"world"
end
end

module Test
def bar
"goodbye"
end
def blah
"new york"
end
end

class Zap
use Foo, :bar
use Test, :blah
end

z = Zap.new

z.bar # "hello"
z.baz # NoMethodError
z.blah # "new york"

# Using the new keywords
class MyKlass
use Foo :alias => {:bar, :test}
end

m = MyKlass.new
m.test # "hello"
m.bar # NoMethodError

It lets us import the method we need rather than whole module.

== Conclusion ==

As illustrated in the examples, there are at least two ways to ensure that your class runs as expected even when using modules with method name conflicts.

The two approaches are:
#calling the module's methods using qualified names
#using an alias

In our opinion, the first approach, calling the module's methods using qualified names, is the better approach. Inheriting from the module and using the qualified names to avoid conflicts is a more efficient OO design. 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.

With the alias approach, the inheritance is limited and the programmer will need to constantly update the list of aliases for methods needed as they arise.

== References ==

#[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
#[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:06:05Z

Arjones3: /* Conclusion */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T19:00:09Z

Arjones3: /* References */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:54:57Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:53:46Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:44:44Z

Arjones3: /* References */

__TOC__

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

== Examples ==

== Conclusion ==

== References ==
[http://www.recentrambles.com/pragmatic/view/69 Modules, Mixins, and Inheritance]
[http://www.rubyist.net/~slagell/ruby/modules.html Ruby User's Guide]

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:27:14Z

Arjones3: /* References */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:22:20Z

Arjones3:

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:16:22Z

Arjones3: /* Background */

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:14:57Z

Arjones3:

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

== Examples ==

== References ==

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:13:51Z

Arjones3: /* Background */

== Background ==
== Examples ==
== References ==

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

== Examples ==

== References ==

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:12:07Z

Arjones3:

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-10-10T18:08:09Z

Arjones3: /* 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

== BACKGROUND ==

== EXAMPLES ==

== REFERENCES ==

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

CSC/ECE 517 Fall 2007/wiki1b 1 as

2007-09-29T14:43:34Z

Arjones3:

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

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:39:50Z

Arjones3:

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:39:09Z

Arjones3:

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

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:37:40Z

Arjones3:

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

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:37:03Z

Arjones3:

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

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:35:58Z

Arjones3: /* 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?'''

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.

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:35:25Z

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

CSC/ECE 517 Fall 2007/wiki1 1 as

2007-09-28T19:34:18Z

Arjones3:

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