On 3/17/07, Meinrad Recheis <meinrad.recheis / gmail.com> wrote:
> 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 prefer to use a proven implementation over hacking my own which i'd
> have to test. but on the other hand i am not happy with having such a
> fat ruby distribution with all the things i never need so I'd rather
> prefer stripping some libs instead of adding new ones. ;)

There are libs a lot fatter than this in the standard package. And
this is pretty fundamental programming stuff.

What would you strip out, though? Libs like Rake, REXML, Webrick, etc.
I would consider those added weight. But what "I never need" is
relative, so it can be pretty hard to decide.

BTW, someone asked for use cases. I recalled one yesterday. I used it
for Infinity. Rather than have two singleton classes, one for positive
Infinity and another for negative Infinity, I just have one multiton
class with a negative/positive attribute.

T.