[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Modules -> do I have is straight?

Jean Nibee

8/9/2006 6:00:00 PM

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-....
17 Answers

Arnaud Bergeron

8/9/2006 6:29:00 PM

0

On 8/9/06, Jean Nibee <theopensourceguy@gmail.com> 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.
>
> 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.

> --
> Posted via http://www.ruby-....
>

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

Justin Collins

8/9/2006 7:25:00 PM

0

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

Jean Nibee

8/9/2006 7:45:00 PM

0

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. :/

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

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

simonh

8/9/2006 8:11:00 PM

0

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?

Bira

8/10/2006 12:28:00 PM

0

On 8/9/06, simonh <simonharrison@fastmail.co.uk> 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.


--
Bira
http://compexplicita.bl...
http://sinfoniaferida.bl...

Rick DeNatale

8/10/2006 5:43:00 PM

0

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.

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

e

8/10/2006 10:27:00 PM

0

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

Rick DeNatale

8/10/2006 11:57:00 PM

0

On 8/10/06, Eero Saynatkari <eero.saynatkari@kolumbus.fi> 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

> Bar.new # Now OK also!



--
Rick DeNatale

Marc Heiler

8/11/2006 2:55:00 PM

0

"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 :)

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

simonh

8/11/2006 6:10:00 PM

0

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