I'm all for people writing their own helper methods if they want them (because people's needs are so wildly different) - my main concern is with the speed of catching an exception and not integrating this into core/more. I _was_ saying that throw/catch is just as clunky as using if/then/else - but after some further reflection throw/catch can reduce much of the clutter over if/then/else - just not as much as raise/rescue. I'm also all for maintainability over prettiness - but for me pretty code is easier to maintain than ugly code, on the average. Just wishing to clarify what my intentions and perceptions are. I figure if I keep quiet than I won't learn as much.
On Dec 4, 11:07 am, "Adam French" <[EMAIL PROTECTED]> wrote: > I don't think there's a "true ruby" way of disabling the backtrace > though I have seen a gem which attempts to hide the backtrace in log > output for rails applications. > > This ofcourse would not be an option for DM because a) it adds a > unneeded dependency to DM and b) would still cause ruby to inspect the > stack (which is the actual performance hit). If you don't want the > stacktrace to be inspected, using throw/catch would be the best way to > go. > > Also, I should point out that many of the core DM contributors value > functional well-organized easy-to-maintain code over 'pretty' code. > This value statement likely needs better verbalizing than that but > it's the main reason why you're not likely to see helper methods > scattered about DM and instead see canonical ruby idioms (or faster > alternatives when available). The closer the API gets to 'plain ol > ruby', the faster new users will be able to pick up DM and the less > overall API 'inertia' has to be overcome while DM grows. > > That being said, I personally wash my hands of this discussion and > defer all decisions to those smarter than I. > === > Adam French > > On Thu, Dec 4, 2008 at 11:46 AM, Eltiare <[EMAIL PROTECTED]> wrote: > > > Is there any way to disable the backtrace? If it's an expected error, > > there should be no need for a backtrace. One of the nice things about > > raising an error is that it also rolls back transactions. It really is > > too bad that it's such a performance hit as rescuing errors makes the > > code so much nicer and readable, IMO. Throw/catch is not a > > replacement for this way of doing things as it does not roll back > > transactions (you'd have to checks after the block). This might > > actually be desirable in the eyes of the DM team, though - as perhaps > > some people don't _want_ a transaction rolled back if there's a > > validation error. Plus it seems like you are still doing if/then/else > > checks if you want to do something differently depending on if there's > > a validation error or not. I'm kinda in the middle on this one. It > > seems to me that GOTO-like statements in this case are not evil > > because they are not global GOTO's - making them much more > > maintainable than the nasty statements of yester-years. Bah, I hate > > it when I have to choose between writing pretty code and writing for > > performance (which seems to be all the time....) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
