Scott Taylor wrote:
> [
"So my main objective with fixjour is to have the simplest
implementation possible, with a very simple API. So it will create the
following methods: new_[model], create_[model], and
valid_[model]_attributes."
This seems to be an anti-pattern in the Rails community:
"I can't follow Library X, so I'll write Library Y, which is lightweight and
obeys YAGNI, and is the simplest possible implementation."
I confess: I've done it too. But it's nearly always the wrong approach. If
you can't follow Library X's *implementation*, but you agree with its
*philosophies*, refactor it!
Competing libraries should have different goals, different purposes,
different anything other than just "cleaner code". If Merb can refactor
itself into Rails, you can do it with fixtures, authentication, file
attachments, or what have you. As easy as Github makes forking, the choice
of libraries should no longer be driven by "this one was updated most
recently" or "this one uses the most recent design idioms".
As someone wrote recently: The minute you start coding, you're writing
legacy code.
Jay Levitt
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
