From: tamouse mailing lists <tamouse.lists@...>
Date: 2013-05-30T07:44:13+09:00
Subject: Re: GEMs pollution or not?

On Wed, May 29, 2013 at 1:58 PM, Denis BEURIVE <lists@ruby-forum.com> wrote:
> Hello,
>
> While developing a module that implements a « CRON calendar », I also
> created a few « utility modules ».
>
> When you develop such module, you write functions that are not coupled
> to your module.
>
> For example : a function that returns the list of "days of the month"
> that correspond to a list of "days of week" (within a given month of a
> given year). This function may be used for other purposes than a « CRON
> calendar ». Therefore, I put this function in a « date utility module ».
>
>
> 1 -- I can include the « date utility module » within the « CRON
> calendar GEM ».
>
> or
>
> 2 -- I can create a « date utility GEM ». The « CRON calendar GEM » will
> have a dependance with the « date utility GEM ».
>
>
> The second solution seems better. But : the « date utility GEM » may
> change in the future, since I'll be adding more and more functions into
> it. In other words : this GEM is a kind of heap of functions with no
> other thing in common than date and time finality.
>
> If everybody creates a GEM for this kind of thing, this may pollute the
> GEM repository.
>
> What's your advice?

First off, look for existing gems with such functionality. If nothing
fits, but something is close, consider contributing to that gem. If
nothing is close, write a new gem.

However, don't use a gem as a junkdrawer. Just because something has
to do with date or time processing, doesn't mean it should all go in
one single gem.

The overall approach of separating things into self-contained modules,
though, is very sound. Just make sure your interfaces to them are an
established contract with your callers/users (which hopefully will
grow to beyond just yoursef). Don't break interfaces. Period. But when
you have to (you really don't!) make sure to version them correctly.