On 3/16/07, James Edward Gray II <james / grayproductions.net> wrote:
> On Mar 15, 2007, at 11:46 PM, TRANS wrote:
>
> > One can
> > of course handle it manually, but the advantages of a general lib are,
> > of course, what you get "for free": a common interface, thread-safety
> > and no issues with hash keys.
>
> I see these points and they are certainly correct, but honestly the
> two or three times I've needed something like this it was trivial to
> just roll it in.  In fact, I don't think I've ever needed a more
> complicated version than:
>
> class OnePerArgs
>    class << self
>      alias_method :__new__, :new
>      def new(*args)
>        (@instances ||= Hash.new)[args] ||= __new__(*args)
>      end
>    end
> end
>
> Even with all of these enhancements you speak of, your library is 36
> lines of code.  I guess I just feel this is a pretty simple problem
> to be solving with a standard library.
>
> I'm not saying I oppose adding it.  I'm just not feeling a huge need.

Yep, your example is the typical way to handle this _at first_. It's
simple enough, true, but it's not robust --it's not thread safe and
hash arguments will fail. So I think it's better to have this simple
mixin available to do it well when one needs it.

T.