Modules -> do I have is straight?

ruby-talk
1

Hi

First off, thanks for letting me be a Ruby noob. I've read most of the
Pickaxe book and most of Why's guide (whee it's in PDF now) and I am
getting comfortable w/ Ruby. Coming from a long Java background I tend
to try and find similarities of things in Ruby to things in Java, simply
to try and 'get' them better.

Modules have messed me up a bit but here's what I understand. (I'm the
only Ruby guy at my office so I have no-one to throw these questions off
of).

Modules in effect 'wrap functionality', they have no other purpose than
to package up code that can be used/imported/inlined into other code and
classes. Since you can't instantiate them, they do nothing by
themselves. They are part of a greater whole.

That being said.. could they be seen (From a functional standpoint) as
an abstract class? In other words, they are a piece of 'incomplete'
functionality that we must implement / use and build on but we can't use
by themselves.

Thanks for your time.

P.S. Do you package Modules in a different place than actual classes? (I
still live like a java programmer and put all my classes in their own
file.)

···

--
Posted via http://www.ruby-forum.com/.

2

Hi

First off, thanks for letting me be a Ruby noob. I've read most of the
Pickaxe book and most of Why's guide (whee it's in PDF now) and I am
getting comfortable w/ Ruby. Coming from a long Java background I tend
to try and find similarities of things in Ruby to things in Java, simply
to try and 'get' them better.

Modules have messed me up a bit but here's what I understand. (I'm the
only Ruby guy at my office so I have no-one to throw these questions off
of).

Modules in effect 'wrap functionality', they have no other purpose than
to package up code that can be used/imported/inlined into other code and
classes. Since you can't instantiate them, they do nothing by
themselves. They are part of a greater whole.

That being said.. could they be seen (From a functional standpoint) as
an abstract class? In other words, they are a piece of 'incomplete'
functionality that we must implement / use and build on but we can't use
by themselves.

Thanks for your time.

Module can "do" things by themselves if you define some module functions:

module Example
   def self.foo(arg)
      puts arg
   end
end

Example.foo("hello") # ouputs "hello"

Think of it like this: Modules are like Java interfaces, but with a
method definition provided.

If you want to be more OO generic, Modules are classes that cannot be
instanciated, but otherwise have all the functionality of classes.

Hoping I am not just confusing you.

P.S. Do you package Modules in a different place than actual classes? (I
still live like a java programmer and put all my classes in their own
file.)

You put them where you want. It's your code after all.

···

On 8/9/06, Jean Nibee <theopensourceguy@gmail.com> wrote:

--
Posted via http://www.ruby-forum.com/.

--
"What is your function in life?" - Killer

3

Jean Nibee wrote:

Hi

First off, thanks for letting me be a Ruby noob. I've read most of the Pickaxe book and most of Why's guide (whee it's in PDF now) and I am getting comfortable w/ Ruby. Coming from a long Java background I tend to try and find similarities of things in Ruby to things in Java, simply to try and 'get' them better.

Modules have messed me up a bit but here's what I understand. (I'm the only Ruby guy at my office so I have no-one to throw these questions off of).

Modules in effect 'wrap functionality', they have no other purpose than to package up code that can be used/imported/inlined into other code and classes. Since you can't instantiate them, they do nothing by themselves. They are part of a greater whole.
  
As Arnaud mentioned, they can 'do' stuff on their own if you create module-level methods. Remember, modules are objects, too.

That being said.. could they be seen (From a functional standpoint) as an abstract class? In other words, they are a piece of 'incomplete' functionality that we must implement / use and build on but we can't use by themselves.
  
Actually, many people like to use them as namespaces as well. Packaging up functionality, as you say. Trying to make sure method names don't conflict with other packages.

Thanks for your time.

P.S. Do you package Modules in a different place than actual classes? (I still live like a java programmer and put all my classes in their own file.)
  
There's nothing wrong with putting each class it its own file, and you can do the same with modules. In fact, you can even spread classes/modules across multiple files, since classes are always 'open'. Or put multiple classes/modules in one file. There is no enforced manner of doing things.

Hope that helps a little.

-Justin

4

Arnaud Bergeron wrote:

Think of it like this: Modules are like Java interfaces, but with a
method definition provided.

If you want to be more OO generic, Modules are classes that cannot be
instanciated, but otherwise have all the functionality of classes.

Hoping I am not just confusing you.

Hmm.. they sound like they do the same thing as Static Methods in Java
AND the package command all in one.

I don't know why I'm so hung up on this.

I wish worked in a more Ruby enabled environment where I could toss
around the discussions, but most of my Java co-workers have the
mentality that "that's nice but it's only good for small applications".
It kills me because I work in some big industries with some smart
people, but they can't see beyond the Java Duke logo on their business
cards. :confused:

Anyhoo, you all haven't seen the last of me so if I'm am ALREADY
annoying, start writing the filters to junk me. :slight_smile:

···

--
Posted via http://www.ruby-forum.com/.

5

A related question: is this why many libraries nest classes inside a
main module?

i.e.

module DataBase
  class Table
    class Column
      ...
    end

   class Row
     ...
   end
end
end

Are their any good explanations of designing programs using this
convention?

6

True as a first approximation. To be more correct as to ruby. A
Module is a container (namespace) which can contain constants, class
variables and methods. Note that the constants can be:

  * simple constants
        Constant = 1
  * classes
        class Foo
         end
  * modules
        module Bar
        end

Classes are subclasses of Module which also provide for instantiation.
When you include(mixin) a module in a class all of the modules
constants, class variables, and methods are added to the class.

And since classes are subclasses of module they can do everything a
module can do, EXCEPT that the include method in Module will complain
if you try to include a class in another class.

···

On 8/9/06, Arnaud Bergeron <abergeron@gmail.com> wrote:

Think of it like this: Modules are like Java interfaces, but with a
method definition provided.

If you want to be more OO generic, Modules are classes that cannot be
instanciated, but otherwise have all the functionality of classes.

--
Rick DeNatale

http://talklikeaduck.denhaven2.com/

7

The one I can think of is to prevent "namespace collisions". So, if
you use the DataBase module, and for some reason you need to create
another class named Tabled in your application, there won't be any
conflicts between the two. Inside your program, you can refer to your
Table class as Table, and to the one inside the module as
DataBase::Table.

···

On 8/9/06, simonh <simonharrison@fastmail.co.uk> wrote:

Are their any good explanations of designing programs using this
convention?

--
Bira


http://sinfoniaferida.blogspot.com

8

Simon Harrison wrote:

A related question: is this why many libraries nest classes inside a
main module?

i.e.

module DataBase
  class Table
    class Column
      ...
    end

   class Row
     ...
   end
end
end

Are their any good explanations of designing programs using this
convention?

This is apart from modules' normal usage as mixins.

The module is just there to provide a structure or a
namespace for the code, similar to Java's packages.

When a programmer #requires your file, they must refer
to your class as DataBase::Table which is useful for all
the normal reasons.

One interesting thing arising from modules in fact being
Modules and the top-level execution context being an Object
is that you can reduce namespaces. In the event that a
programmer does not want to use your DataBase namespace
everywhere, they can #include it just like any other
Module and thereby mixing in its contents with normal
mixin semantics:

module Foo
   Class Bar
   end
end

Bar.new # Error
Foo::Bar.new # OK

include Bar

Bar.new # Now OK also!

···

--
Posted via http://www.ruby-forum.com/.

9

module Foo
   Class Bar
   end
end

Bar.new # Error
Foo::Bar.new # OK

include Bar

Or maybe

     include Foo

You can only include a module, not a class, even include Foo::Bar wouldn't work

···

On 8/10/06, Eero Saynatkari <eero.saynatkari@kolumbus.fi> wrote:

Bar.new # Now OK also!

--
Rick DeNatale

10

"Are their any good explanations of designing programs using this
convention?"

Its just to add nicer Namespaces to your class.

People often write many classes, and define them in the
same Namespace (part of the module).
I think it helps them to use, and remember them, together.

From an usage point of view, using:

  Foo::Bar.new

is not that much extra work than

  Bar.new

And if you still dont want the first, you can
include the module (and the namespace), and
make the 2nd version work. Totally up to
you - I personally usually use the longer way
though :slight_smile:

···

--
Posted via http://www.ruby-forum.com/.

11

thanks for the clarification. sorry for hijacking your thread jean!

12

I was hoping I could expand on the thread a little bit...

I sort of understand modules, according to what I have read in my fancy
ruby book and this forum modules are like superclasses. But, what about
this < ?
Doesn't this allow a class to "become" a subclass of another by way of
inheritance. Not sure I am catching the difference between the two.

Also, I am not quite sure I understand how namespaces works in ruby.
In java you create a package ( i know you all know this already I am
just saying it for my benefit) to place related classes in. Say for
example com.jenkins.util.MyFancyClass. If I want to use this class in
another package com.jenkins.library any classs in library would just
import it. How does this work in ruby?
Most of the code I have seen is in the same class or at least the same
direcctory. Is it typical for ruby applications to create a package
structure similar to a java app?

Thanks for your time!

···

--
Posted via http://www.ruby-forum.com/.

13

I was hoping I could expand on the thread a little bit...

I sort of understand modules, according to what I have read in my
fancy ruby book and this forum modules are like superclasses. But,
what about this < ?
Doesn't this allow a class to "become" a subclass of another by way of
inheritance. Not sure I am catching the difference between the two.

class Base
end

class Descendant < Base
end

Descendant is a subclass of Base.

module Foo
end

class Bar
  include Foo
end

Foo is mixed into Bar. You can combine both approaches.

class Deri2 < Base
  include Foo
end

Deri2 inherits Base and mixes in Foo. You can use instance methods from Base and Foo in Deri2.

Also, I am not quite sure I understand how namespaces works in ruby.
In java you create a package ( i know you all know this already I am
just saying it for my benefit) to place related classes in. Say for
example com.jenkins.util.MyFancyClass. If I want to use this class in
another package com.jenkins.library any classs in library would just
import it. How does this work in ruby?

module com
  module jenkins
    module util
      class MyFancyClass
      end
    end
  end
end

Now you have

com::jenkins::util::MyClass

Or you do

include com::jenkins::util
MyClass

Most of the code I have seen is in the same class or at least the same
direcctory. Is it typical for ruby applications to create a package
structure similar to a java app?

You can do that. From what I've seen though these hiearchies are not as deep as they are usually in Java.

Kind regards

    robert

···

Carl Jenkins <carljenkins@gmail.com> wrote:

14

I was hoping I could expand on the thread a little bit...

I sort of understand modules, according to what I have read in my fancy
ruby book and this forum modules are like superclasses. But, what about
this < ?
Doesn't this allow a class to "become" a subclass of another by way of
inheritance. Not sure I am catching the difference between the two.

Both modules and classes can become the ancestors of a class. The difference is that only one class may be the direct parent of a given class will the class can have any number of modules as its parent. A class designates another class as its parent with < and it designates modules as its parents with 'include'. The point of distinguishing between classes and modules may be hard to grasp until you deal with a language like C++ that allows multiple inheritance without making the distinction. In the C++ case you may have to resort to complicated rules to figure out what a given method call will do because the inheritance chain can be ambiguous. I'm sure many here can elaborate if you are curious about why distinguishing between classes and modules simplifies things.

Also, I am not quite sure I understand how namespaces works in ruby.
In java you create a package ( i know you all know this already I am
just saying it for my benefit) to place related classes in. Say for
example com.jenkins.util.MyFancyClass. If I want to use this class in
another package com.jenkins.library any classs in library would just
import it. How does this work in ruby?
Most of the code I have seen is in the same class or at least the same
direcctory. Is it typical for ruby applications to create a package
structure similar to a java app?

In Ruby there is no imposed correspondence between the namespace hierarchy and the file system. If you are writing and application for a furniture store and you want to distinguish between Database::Table and Inventory::Table you just do it.

I was just using Why's Hpricot module. Now Hpricot is a weird word that is very unlikely to collide with anything in my code. Inside it are things like Hpricot::Element and Hpricot::Text and Hpricot::Traverse. These are all names that might well collide with my own names or names from other libraries if they weren't in a separate namespace. The organization of the files within Hpricot is along a different principle. many of the names are defined in more than one file.

HTH

···

On Aug 12, 2006, at 6:06 AM, Carl Jenkins wrote:

--
The folly of mistaking a paradox for a discovery, a metaphor for a proof, a torrent of verbiage for a spring of capital truths, and oneself for an oracle, is inborn in us.
-Paul Valery, poet and philosopher (1871-1945)

15

I sort of understand modules, according to what I have read in my fancy
ruby book and this forum modules are like superclasses. But, what about
this < ?
Doesn't this allow a class to "become" a subclass of another by way of
inheritance. Not sure I am catching the difference between the two.

Yes, Single inheritance in Ruby. You'll specialize the parent class
after the
<
You can extend your objects with modules at runtime too,
foobar.extend()
And you can scope to the parentclass (and their methods) by invoking
super(),
I think it would be easiest if you make some tiny classes, and subclass
them. Then add a module and see how super is resolved

As for your second question, maybe someone else can help you more.

···

--
Posted via http://www.ruby-forum.com/.

16

Carl Jenkins wrote:

I was hoping I could expand on the thread a little bit...

I sort of understand modules, according to what I have read in my fancy
ruby book and this forum modules are like superclasses. But, what about
this < ?
Doesn't this allow a class to "become" a subclass of another by way of
inheritance. Not sure I am catching the difference between the two.

Modules should really not be used like superclasses--although
you are correct, an #included module does become an ancestor
of the #including class and method lookup follows this. The
commonly used name for the module behaviour is 'mixin'.

I personally prefer modules for mainly two cases:

1) 'Intersecting' behaviour, something that is added to multiple
   classes as an enhancement but does not really make the classes
   'related' enough for an inheritance relationship.

2) Variable composition--a class can be customised/enabled/disabled
   for certain tasks by adding/withholding/changing its module
   composition. This can, of course, also be achieved by either
   actual composition by variables or then by subclassing.

Also, I am not quite sure I understand how namespaces works in ruby.
In java you create a package ( i know you all know this already I am
just saying it for my benefit) to place related classes in. Say for
example com.jenkins.util.MyFancyClass. If I want to use this class in
another package com.jenkins.library any classs in library would just
import it. How does this work in ruby?
Most of the code I have seen is in the same class or at least the same
direcctory. Is it typical for ruby applications to create a package
structure similar to a java app?

The namespace, unlike in Java, is in no way enforced and it
cannot be used to resolve a file's location in the filesystem.
It is strictly a convenience to give the code some structure
and to insulate it from namespace clashes.

It is certainly possible to put your code in a similar namespace
to what you would use in Java:

  module Com
    module Company
      module ProjectName
        module LibraryName
          class SomeClass
            # ...
          end
        end
      end
    end
  end

Typically, though, only the ProjectName/LibraryName downwards
is used.

I think the most common file layout is the one required by
install.rb/setup.rb (see http://raa.ruby-lang.org) or, more
recently, RubyGems.

···

Thanks for your time!

--
Posted via http://www.ruby-forum.com/.

17

of course in Java it's common practice to use the root levels of the
package naming hierarchy to identity the organizational source of the
package using a reversed dns name.

e.g.

org.osgi.framework
org.osgi.service.cm
org.osgi.util.measurement
com.ibm.db2.app
com.ibm.oti.vm
org.eclipse.swt.widgets

The top-levels of these hierarchies are (usually) empty.

···

On 8/12/06, Robert Klemme <shortcutter@googlemail.com> wrote:

> Most of the code I have seen is in the same class or at least the same
> direcctory. Is it typical for ruby applications to create a package
> structure similar to a java app?

You can do that. From what I've seen though these hiearchies are not as deep
as they are usually in Java.

--
Rick DeNatale

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/

18

Eero Saynatkari wrote:

Also, I am not quite sure I understand how namespaces works in ruby.
In java you create a package ( i know you all know this already I am just saying it for my benefit) to place related classes in. Say for example com.jenkins.util.MyFancyClass. If I want to use this class in another package com.jenkins.library any classs in library would just import it. How does this work in ruby?
Most of the code I have seen is in the same class or at least the same direcctory. Is it typical for ruby applications to create a package structure similar to a java app?

The namespace, unlike in Java, is in no way enforced and it
cannot be used to resolve a file's location in the filesystem.

Note that in Java this is in no way enforced either - just the convention is more ubiquitous because default class loaders implement it. If you have the proper class loader you can lump all class files into a single directory.

Kind regards

  robert