Rails core - Mar 2013 - link_to should have its body and url arguments reversed

I think the link_to helper method is quite confusing with its arguments 
order:

    link_to body, url
    link_to "Click me", @person

Why is it thay way round? I want to make a "link to [the] person", so
I
would expect the order to be:

    link_to @person, "Click me"

It reads much more natural. You don''t "link to [the] body",
you "link to
[the] url". So the order schould be

    link_to url, body, options={}

Is there a rationale for the current arguments order?

I know, changing it would break compatibility but I think it''s worth 
considering.

- Michael

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

A less destructive approach would be to use Ruby 2.0''s named arguments
to have something like:

link_to url: @person, body: "Click me"

That being said, I understand your point, but don''t see it as a
particular pain.

On Mar 15, 2013, at 12:58 PM, Michael Grohn wrote:
> I think the link_to helper method is quite confusing with its arguments
order:
> 
>     link_to body, url
>     link_to "Click me", @person
> 
> Why is it thay way round? I want to make a "link to [the]
person", so I would expect the order to be:
> 
>     link_to @person, "Click me"
> 
> It reads much more natural. You don''t "link to [the]
body", you "link to [the] url". So the order schould be
> 
>     link_to url, body, options={}
> 
> Is there a rationale for the current arguments order?
> 
> I know, changing it would break compatibility but I think it''s
worth considering.
> 
> - Michael
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
Cumprimentos,
Luís Ferreira



-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Mar 15, 2013, at 8:58 AM, Michael Grohn wrote:
> I think the link_to helper method is quite confusing with its arguments
order:
> 
>     link_to body, url
>     link_to "Click me", @person
> 
> Why is it thay way round? I want to make a "link to [the]
person", so I would expect the order to be:
> 
>     link_to @person, "Click me"
> 
> It reads much more natural. You don''t "link to [the]
body", you "link to [the] url". So the order schould be
> 
>     link_to url, body, options={}
> 
> Is there a rationale for the current arguments order?
I''d guess that it''s because while the body is typically simple
(a string or variable), the second argument can also be a bunch of params for
url_for:

link_to ''thingy'', :controller => ''wat'',
:action => ''huh'', :protocol => ''wtf''

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

@Matt jones
> I''d guess that it''s because while the body is typically
simple (a string
or variable), the second argument can also be a bunch of params for 
url_for: 
> 
> link_to ''thingy'', :controller =>
''wat'', :action => ''huh'', :protocol =>
''wtf'' 

There are 4 signatures for the link_to helper method:

    link_to(body, url, html_options = {})
    link_to(body, url_options = {}, html_options = {})
    link_to(options = {}, html_options = {})
    link_to(url, html_options = {})

Your example would fit the second signature, which has no url argument, but 
a url_options hash instead. This is fine, options always go at the end of a 
method call.

The first signature is the one that bothers me.



@Zamith
> link_to url: @person, body: "Click me"
I thought of that one too, but it''s almost just as ugly as

    link_to "Click me", @person



Another reason why it bothers me, is that the body can also be given as a 
block, in which case, tho body goes at the very end of the method call and 
the url at the beginning. So in case of a block-given body, the order is 
just reversed:

    link_to @person do "Click me" end

Not very consistent, he?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

You can always use

link_to @person { "Click me" }

if you find that infinitely more readable than

link_to "Click me", @person

without the need to introduce a backwards incompatible change that would
break every Rails app ever written.


On Fri, Mar 15, 2013 at 3:39 PM, Michael Grohn
<grohn.michael@gmail.com>wrote:
> @Matt jones
>
> > I''d guess that it''s because while the body is
typically simple (a string
> or variable), the second argument can also be a bunch of params for
> url_for:
> >
> > link_to ''thingy'', :controller =>
''wat'', :action => ''huh'', :protocol =>
> ''wtf''
>
> There are 4 signatures for the link_to helper method:
>
>     link_to(body, url, html_options = {})
>     link_to(body, url_options = {}, html_options = {})
>     link_to(options = {}, html_options = {})
>     link_to(url, html_options = {})
>
> Your example would fit the second signature, which has no url argument,
> but a url_options hash instead. This is fine, options always go at the end
> of a method call.
>
> The first signature is the one that bothers me.
>
>
>
> @Zamith
>
> > link_to url: @person, body: "Click me"
>
> I thought of that one too, but it''s almost just as ugly as
>
>     link_to "Click me", @person
>
>
>
> Another reason why it bothers me, is that the body can also be given as a
> block, in which case, tho body goes at the very end of the method call and
> the url at the beginning. So in case of a block-given body, the order is
> just reversed:
>
>     link_to @person do "Click me" end
>
> Not very consistent, he?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Mar 15, 2013, at 2:39 PM, Michael Grohn wrote:
> @Matt jones
> 
> > I''d guess that it''s because while the body is
typically simple (a string or variable), the second argument can also be a bunch
of params for url_for:
> > 
> > link_to ''thingy'', :controller =>
''wat'', :action => ''huh'', :protocol =>
''wtf''
> 
> There are 4 signatures for the link_to helper method:
> 
>     link_to(body, url, html_options = {})
>     link_to(body, url_options = {}, html_options = {})
>     link_to(options = {}, html_options = {})
>     link_to(url, html_options = {})
> 
> Your example would fit the second signature, which has no url argument, but
a url_options hash instead. This is fine, options always go at the end of a
method call.
> 
> The first signature is the one that bothers me.
It''s ultimately a matter of symmetry, especially when switching from a
hash to a URL helper:

  link_to ''something'', :controller =>
''posts'', :action => ''show'', :id => id

becomes:

  link_to ''something'', post_path(id)

Requiring that the arguments trade positions between those two lines would be
seriously annoying.

BTW, the bikeshed should TOTALLY be painted blue. ;)

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.