On 28 Apr 2006, at 01:39, Eduardo Rocha wrote: > I bet you once felt as guilty as me and just learned let it go! :) > Thanks for conving me on this one, I really needed some support > here :)
Yup, of course. You know what though, this could be seen as a bug. The problem is, how do you fix it. If you think there is a better way to do it, go for it. > Nice to know. I was kind of struggling with DRY DRY DRY all over my > head, and honestly I am looking forward being more pragmatic and know > better how to balance these concerns. I feel Rails has this kind of > culture, DHH once wrote a controversial post about 'reuse is > overrated' and I am still getting to grips with thoughts like that. > Surely this email will help me, thanks a lot! There are no absolutes in this game, just pretty good guesses. DRY is a really excellent way of producing good code and in the long run more adaptable and flexible code. The one thing I hate about some of the way things have developed in the last year is how what DHH says is seen as 100% correct for all situations, and some of the things he says just aren't that concrete. In fact if you read the article you're referring to he says "usually that means it'll take more time to reuse something than it'll take to create it from scratch", which is correct. People miss the "usually" at the start though and read it as "it'll take more time..." and get in to a state of coding paralysis. In another part he says: "When you try to [sic] hard to reuse, you'll often end up with a frankenstein of slightly different approaches and philosophies that creates rough, unpolished surfaces that simply can't make you happy because it can't be beautiful." OK, but reuse in this particular context does not create a rough and unpolished surface that isn't beautiful. It's beautiful because: a) It's a well-documented case b) It's an elegant way of doing it c) It's best of both worlds - you get all that functionality that you're not copying and pasting and still getting a really customised version of the engines you need d) You're not going to distribute this code to anybody other than as a finished product, or maybe as an engine itself Look at how user_engine is built on top of login_engine, and you will see why reuse, over-riding this way is jaw-droppingly beautiful. And if you really aren't into re-use, technically you shouldn't be using scaffolds. Or generators of any sort. Or Rails. Here's a good counter-argument to the article you read: http://www.nshb.net/reuse- is-definately-not-overrated So, think about what you're doing: you're not repeating yourself in the obtuse copy'n'paste because you're too lazy to work out how to inherit, kind of way, you're doing something which is a perfectly valid way of re-defining a method to do something different. This is the Ruby way. Doing it this way is the Ruby way, not the C way where you'd end up creating a copy of the whole controller just to change one line - you're copying just one method and moulding it around what you need, letting the other methods live back in /vendor/plugins If you can work out a 100% non-repeating way of getting the same effect, cool, let's see it! I bet it'd be damn ugly though... And stop drinking the DHH Kool Aid. :-) Good luck with your project! -- Paul Robinson _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
