Under normal circumstances it's fine to require the same file twice, because require keeps a record of the libraries it has loaded and ignores a second call.
It looks as if you get this error if the library you are requiring requires itself somehow, which is not something that require can cope with -- the require operation presumably needs to complete before the library is added to the list.
So if in a.rb you require b.rb and in b.rb you require a.rb. then when you write `require "a"` Ruby will
* start to require a.rb
* start to require b.rb
* start to require a.rb again and realise there is something terribly wrong.
Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.
I'm reading Ousterhout's "A Philosophy of Software Design" and seeing the need to reduce the complexity of my program. Looks like this is another area to work on!
Leam
···
On 9/21/18 4:57 AM, Andy Jones wrote:
Under normal circumstances it's fine to require the same file twice, because require keeps a record of the libraries it has loaded and ignores a second call.
It looks as if you get this error if the library you are requiring requires itself somehow, which is not something that require can cope with -- the require operation presumably needs to complete before the library is added to the list.
So if in a.rb you require b.rb and in b.rb you require a.rb. then when you write `require "a"` Ruby will
* start to require a.rb
* start to require b.rb
* start to require a.rb again and realise there is something terribly wrong.
Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.
This is pretty common mistake (I think) and is a signal that your code is too
coupled.
This. In my case the thing that got me thinking clearly about dependency and coupling was POODR ("Practical Object Oriented Design in Ruby", by Sandi Metz).
Short version: class B shouldn't really care whether that object passed as a method parameter is a class A object or not. It should only care that whatever the object is, it can behave in the right way...
Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.
Agreed. The issue came from moving everything into a module before I really understood the full level of modularity needed. I've read POODR a couple times but didn't "get" it; now that I have a need perhaps another re-read is in order.
···
On 9/21/18 6:04 AM, Andy Jones wrote:
>
This is pretty common mistake (I think) and is a signal that your code is too
coupled.
<
This. In my case the thing that got me thinking clearly about dependency and coupling was POODR ("Practical Object Oriented Design in Ruby", by Sandi Metz).
Short version: class B shouldn't really care whether that object passed as a method parameter is a class A object or not. It should only care that whatever the object is, it can behave in the right way...