From: Josh Cheek Date: 2013-05-29T22:52:45+09:00 Subject: Re: GEM and module? Could a GEM be a module? --001a11c25a8e18fcab04dddbb2a1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 8:11 AM, Denis BEURIVE wrote: > Hello, > > I have written a library that calculates dates based on CRON > specifications. I'd like to publish it as a GEM. > > In order to avoid name collisions, I create a module ("Cron") that holds > all the classes that build the library. In fact the is two classes : > > Cron::Calendar > Cron::NoNextExecution > > In your code, you write : c = Cron::CronCalendar.new(...) > > As you may wish, the second class represents an exception that is raised > if it is not possible to find the date of the next execution (this may > occur if the CRON specification defines a range for the year). I > included this class within a module because the name of the class may be > used in another context (that is, in another GEM). For example, you > write a workflow processor... You may want to define an exception > "NoNextExecution". > > My question is : > > Is it correct to say : "my GEM is a module" ? > > No, that doesn't really make sense. A gem is a way of organizing and distributing code, a module is a type of Ruby object. You could say that you distribute your module with a gem, but I can't really think of a situation where this phrase would come up. People are interested in what the gem does "I have a gem that calculates dates based on the cron specification" and how to use it "You say `Cron::Calendar.new(...)`" but nobody really cares whether the namespace is a class or a module, and typically aren't even going to ask if it exists (though they'll notice if it's absent). > Or should I "remove" the classes from the module ? (that is: no module > at all). But in this case, name collisions may occur. > > No, you should keep them namespaced, for the reasons you laid out. -Josh --001a11c25a8e18fcab04dddbb2a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 28, 2013 at 8:11 AM, Denis BEURIVE <lists@ruby-forum.com> wrote:

Hello,

I have written a library that calculates dates based on CRON
specifications. I'd like to publish it as a GEM.

In order to avoid name collisions, I create a module ("Cron") tha= t holds
all the classes that build the library. In fact the is two classes :

Cron::Calendar
Cron::NoNextExecution

In your code, you write : c =3D Cron::CronCalendar.new(...)

As you may wish, the second class represents an exception that is raised if it is not possible to find the date of the next execution (this may
occur if the CRON specification defines a range for the year). I
included this class within a module because the name of the class may be used in another context (that is, in another GEM). For example, you
write a workflow processor... You may want to define an exception
"NoNextExecution".

My question is :

Is it correct to say : "my GEM is a module" ?

No, that doesn't really make sense= . A gem is a way of organizing and distributing code, a module is a type of= Ruby object. You could say that you distribute your module with a gem, but= I can't really think of a situation where this phrase would come up. P= eople are interested in what the gem does "I have a gem that calculate= s dates based on the cron specification" and how to use it "You s= ay `Cron::Calendar.new(...)`" but nobody really cares whether the name= space is a class or a module, and typically aren't even going to ask if= it exists (though they'll notice if it's absent).

Or should I "remove" the classes from the module ? (that is: no m= odule
at all). But in this case, name collisions may occur.

No, you should keep them namespaced, f= or the reasons you laid out.

--001a11c25a8e18fcab04dddbb2a1--