On 8/21/07, James Adam <[EMAIL PROTECTED]> wrote: > > On 8/21/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > It does, however, add a whole other method to our supported api. > > Every feature we add has to be supported in future releases. Saving > > 10 keystrokes isn't quite enough to get over that hump.
That, or the continuing question "where did this method come from?" > My point was really that a couple of Rdoc-umentable methods might be > better than a swathe of dynamically-generated ones. It's an > interesting question - is User.find_by_name part of the supported API? > It is... but only when the users table has a name column. > > > There are some unanswered questions though: > > > > * How would it work with options like :order, :include > > * Does it return :first or :all? the name implies :first but your > > proposed implementation is :all. > > The implementation specifics are certainly important, but distract > from the idea I was trying to put forward, which is to use concrete > methods that can be documented in code than dynamically generating > them, except where there are substantial benefits (such as the > attribute accessors, for example). That's where I was headed. Yay! > > > I hardly think that Site.find_by_domain(request.host) is anywhere near > > as magic as some of the edge cases in routes. Which do you prefer? Site.find_by_domain(request.host) Site.find_by(:domain, request.host) The former has less symbols, the latter is more searchable-in-the-API and while it only covers a simple use-case, I feel it's "better". --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
