Closed crystalneth closed 14 years ago
Ok, I was wrong about (3) - that was the me using the gem wrong. 1+2 I stand by.
2) fixed via your pull request. 1) A lot of the modifications are pragmatic: "def foo() ... end unless Bar.respond_to?(:foo)". I'll make them all pragmatic.
aaand done.
Thanks. Sorry for the harsh language. Modifying core objects is a pet pieve of mine.
I don't believe there is any "pragmatic" modification of core objects for a gem like this, that one would not expect to do this type of thing.
If I use this on some obscure admin page of my site, so it is in my Gemfile, and another extension decides it's "pragmatic" to use the same method name for subtly different behavior, it will break something and make it really difficult to track.
This is one of the worst common practices in Ruby and has been denounced by many of the core Rails folks. Rails does this, but they're modifications are well documented and Rails is the core of any application importing that code. I'd prefer they didn't do this kind of stuff either, but nothing is perfect.
Anyway, I'm glad you made this somewhat less bad.
I'm open to patches if you'd to help teach me another elegant way of accomplishing this :)
This gem: 1) Modifies core objects, including Object, Module, String, Hash, etc. completely unnecessarily. This should be using functional methods and leave the rest of my code alone.
2) Those modifications in non-namespaced files, such as 'extensions/object.rb', so that any other gem that does a similarly stupid think (namely faker) conflicts and causes issues. They shoudl be in 'dropbox/extensions/object.rb'
3) The gem seems to depend on methods similarly monkey-patched that are not defined in the gem, namely sub! in api.rb.
Right now this gem is not usable for me.