Re: GEMs pollution or not?

On Wed, May 29, 2013 at 1:58 PM, Denis BEURIVE <[e-mail]> wrote=
:
> Hello,
>
> While developing a module that implements a =C2=AB CRON calendar =C2=BB, =
I also
> created a few =C2=AB utility modules =C2=BB.
>
> 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 =C2=AB C=
RON
> calendar =C2=BB. Therefore, I put this function in a =C2=AB date utility =
module =C2=BB.
>
>
> 1 -- I can include the =C2=AB date utility module =C2=BB within the =C2=
=AB CRON
> calendar GEM =C2=BB.
>
> or
>
> 2 -- I can create a =C2=AB date utility GEM =C2=BB. The =C2=AB CRON calen=
dar GEM =C2=BB will
> have a dependance with the =C2=AB date utility GEM =C2=BB.
>
>
> The second solution seems better. But : the =C2=AB date utility GEM =C2=
=BB 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.