From: Trans <transfire@...>
Date: 2006-09-03T01:17:17+09:00
Subject: Re: Best practice? libs and modules


khaines@enigo.com wrote:
> On Sat, 2 Sep 2006, Trans wrote:
>
> >> So, for example, I have added some things to String and Hash, but don't
> >> want to either force my users to use my extensions, or interfere with my
> >> users ability to use their own extensions.  So, any place where I am going
> >> to need one of those extensions, I work with Iowa::String or Iowa::Hash
> >> instead of String and Hash.  It's a little more typing for me, but better
> >> for my users.
> >
> > There's a downside to this though. To take advantage of those
> > extensions your uses have to use these special subclasses too. As long
> > as your not changing the behavior of a built-in you're generally okay.
>
> No, it really doesn't matter if I am changing the behavior of a built in
> or not (which I'm not).
>
> If I just opened String and put my extensions into there, I'd run the
> substantial risk that someone might use a core extension from
> Rails' ActiveSupport or Facets that conflicts.  And even if there are no
> conflicts today, tomorrow there might be.
>
> Or if I just used LRUCache instead of Iowa::Caches::LRUCache, and someone
> decided to use the Facets LRUCache in an app, it would cause bad things to
> happen (I like the Facets LRUCache's simplicity; I hate that it requires
> extending anything that is to be stored in it, BTW).

Hmm... If you have a fix for that I'd love to incorporate it.

> So yes, if one of my users wants to take advantage of something I have
> in one of the extensions, they have to type a few more characters to
> create the object.  I am quite willing to sacrafice a few characters for
> the relative security against namespace collisions, though.  The cost is
> very small, and the benefit is large.

But then how will I use Kirk's String extensions and Tom's string
extensions?

It's a tade off and what we really need is proper namespaces to fix the
problem.

T.