On Sun, Sep 16, 2012 at 10:41 AM, Dami=E1n M. Gonz=E1lez
<lists / ruby-forum.com>wrote:

> Josh Cheek wrote in post #1076220:
>
> > No, I'm saying don't do this. You can count dog legs since that's a
> > single
> > object, but don't implicitly try to track all of the dogs.
>
>  Well but I don't see another way of keep track of the objects which
> I'll have to work around. I do this in many cases:
>
> class Foo
>   @instances =3D []        #can be a Hash too, whatever
>   class << self
>     attr_accessor :instances
>   end
>   attr_accessor :nickname
>   initialize(nickname)
>     @nickname =3D nickname
>     Foo.instances =3D Foo.instances.push(self)
>   end
> end
>
>  Do you say that I do not have to do this? How can I keep track of the
> instances so, if I want to refer them in the future? 'cause later meaby
> I'll need to do this:
>
> Foo.instances.each do |x|
>   puts x.nickname
> end
>
>
Yeah, I would not do this. If you want to keep track of them, then
explicitly add them to a collection.

foo =3D Foo.new
foos << foo

Now, when foos gets garbage collected, your instances get garbage collected
(As opposed to the example above, where the class is always referenced by
the constant, and always references the collection containing the
instances, these instances are essentially permanent).


Furthermore, it allows the user to decide how to use the code. Do they want
to keep it in a collection? Then they can put it in a collection. Do they
want to just have one of these instances for a bit and then throw it away?
They can do that, too.

Lets say you want to do what Rails does with its rail ties, where they need
to hook into the system life cycle. Rails does it like this
https://github.com/rails/rails/blob/2801786e1a51b7cf7d7c3fd72b5fc9974f83f43=
5/railties/lib/rails/railtie.rb#L125-134Which
is basically what it sounds like you're trying to do. This makes
decisions for users that Rails should not be making. The hoops I have had
to jump through to get away from this kind of invasive decision making
(even when it was my own dumb decisions in my own code) would widen your
eyes. If you want this kind of global registry of instances, let the
instantiator add the class to the registry.

Here is how I have handled this in my own code:

I have a gem that tests code samples embedded in files like READMEs. To
test the code sample, you need to know what strategy to use (i.e. run it
through rspec). The tests need to be able to specify what strategy they
should be run with, thus I maintain a list of strategies. But I do not
auto-add them, I allow whoever is creating the strategies to decide whether
they want it added to this list or not. Here is the code that maintains the
strategies:

https://github.com/JoshCheek/mountain_berry_fields/blob/73e4c1e847c1029a384=
d84857db3a625d5cf74d4/lib/mountain_berry_fields/test.rb#L30-48

Here is an example of an actual strategy, note that it explicitly registers
itself:

https://github.com/JoshCheek/mountain_berry_fields-magic_comments/blob/f9f3=
8fb769eba058c14ffe0c0c14b46c2d891208/lib/mountain_berry_fields/test/magic_c=
omments.rb#L14