I strongly oppose this. Adding the ability to be less explicit with associations seems like magic for magic's sake, to avoid explicitly mapping associations.
bougy On Wednesday, October 31, 2012 1:53:56 PM UTC-5, Tyler Kellen wrote: > > Here is a followup conversation from IRC. > * > * > *jeremyevans: *I responded to your sequel-talk post :) > *tkellen:* Just FYI, this was a total dick thing to say: *If even a > contrived example can't use the proposed feature correctly, is it really > needed?* > *jeremyevans:* Fair enough, sorry about that. But you should check your > example before posting. > *tkellen:* So, my example was incorrect and your main argument is simply > that you don't want "yet another option?" > *tkellen:* I haven't looked at the code yet but i can't imagine something > this simple would add much in the way of complexity > *jeremyevans:* For half of the association types, the option is of zero > value > *jeremyevans:* For the other half, it's of extremely limited value > *tkellen:* I guess we differ on what extremely limited value is. Isn't > the whole point of the association helper methods to help making > associations easy? > *jeremyevans:* Brevity is not the be-all end all. It's not just the > complexity, it's that specifying the 2 or 3 options explicitly is more > clear and overall better than hiding them behind this new option you propose > *tkellen:* By that logic you shouldn't have the association helpers at > all. > *tkellen:* I think my option is more clear than cluttering up the > definition with information that can already be inferred. > *jeremyevans: *We will see if other Sequel users agree, I guess :). > > On Wednesday, October 31, 2012 1:36:09 PM UTC-5, Jeremy Evans wrote: >> >> On Wednesday, October 31, 2012 9:25:26 AM UTC-7, Tyler Kellen wrote: >>> >>> It'd be nice if you could optionally define the name for methods created >>> when adding an association. >>> >>> Here is a contrived example: >>> >>> class Fan < Sequel::Model >>> one_to_many :artists >>> end >>> >>> Say you want to reference a fan's favorite artists as 'friends' instead >>> of 'artists', as in: Fan[:id=>1].friends instead of Fan[:id].artists. >>> Right now, the only way to do that is to use the first argument as the >>> name and explicitly define the rest of the association, like so: >>> >>> class Fan < Sequel::Model >>> one_to_many :friends, :class => :Artist, :key => :artist_id >>> end >>> >>> It'd be nice if you could just do: >>> class Fan < Sequel::Model >>> one_to_many :artists, :name => :fans >>> end >>> >>> This still takes advantage of inflection based configuration, but allows >>> you to control the resulting method names. I'm happy to submit a PR for >>> this, but Jeremy requested feedback from the community before he'd consider >>> the addition. >>> >> >> Basically, I'm leaning against this, so unless I see broad community >> support for it, I don't plan on adding this feature. My main reason >> against adding it is that adds yet another option, for the sole purpose of >> making defining associations very slightly less verbose for many_to_one and >> many_to_many associations. >> >> Your contrived example doesn't make sense to me. For one_to_many >> associations, the :key option is not inferred from the association name, >> and would default to fan_id. If even a contrived example can't use the >> proposed feature correctly, is it really needed? >> >> IIRC, for one_to_many and one_to_one associations, the only option >> inferred from the association name is the :class option, so for those >> associations, a separate association option to set the base name makes no >> sense. For many_to_one associations, both :class and :key are inferred >> from the association name, so in that case you would be saving one option. >> For many_to_many, :class, :join_table, and :right_key are inferred from the >> association name, so you would only be saving two options there. >> >> Personally, I think it's better to explicitly specify both :class and >> :key for many_to_one and :class, :join_table, and :key for many_to_many >> than to add another option that overrides the base name used for the >> defaults for those options. >> >> Jeremy >> > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/gwlZim6G1FAJ. 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/sequel-talk?hl=en.
