Josh Cheek wrote in post #1076220:

> No, I'm saying don't do this. You can count dog legs since tha= t's a
> single
> object, but don't implicitly try to track all of the dogs.

=A0Well 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
=A0 @instances =3D [] =A0 =A0 =A0 =A0#can be a Hash too, whatever
=A0 class << self
=A0 =A0 attr_accessor :instances
=A0 end
=A0 attr_accessor :nickname
=A0 initialize(nickname)
=A0 =A0 @nickname =3D nickname
=A0 =A0 Foo.instances =3D Foo.instances.push(self)
=A0 end
end

=A0Do 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|
=A0 puts x.nickname
end

= =A0

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 &= lt;< foo

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

Furthermore, it allows the user to decide how to use the code. Do t= hey 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 i= t 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/b= lob/2801786e1a51b7cf7d7c3fd72b5fc9974f83f435/railties/lib/rails/railtie.rb#= L125-134 Which 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 tha= t tests code samples embedded in files like READMEs. To test the code sampl= e, you need to know what strategy to use (i.e. run it through rspec). The t= ests 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 whoev= er 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/73e4c1e847c1029= a384d84857db3a625d5cf74d4/lib/mountain_berry_fields/test.rb#L30-48

Here is an example of an actual strategy, note that it explicitly regis= ters itself:

https://github.com/JoshCheek= /mountain_berry_fields-magic_comments/blob/f9f38fb769eba058c14ffe0c0c14b46c= 2d891208/lib/mountain_berry_fields/test/magic_comments.rb#L14