Modules -> do I have is straight?

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

On 8/9/06, Jean N. [email protected] wrote:

of).

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.

Jean N. wrote:

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

Arnaud B. 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:

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?

“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:

Simon H. 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!

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!

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.

Carl J. 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!

On 8/9/06, simonh [email protected] wrote:

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

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/10/06, Eero S. [email protected] wrote:

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

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

On 8/9/06, Arnaud B. [email protected] 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.

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.


Rick DeNatale

http://talklikeaduck.denhaven2.com/

On Aug 12, 2006, at 6:06 AM, Carl J. 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.

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


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)

Carl J. [email protected] 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.

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

On 8/12/06, Robert K. [email protected] 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.

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.


Rick DeNatale

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

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

Eero S. wrote:

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