This project is archived and is in readonly mode.
Array#to_proc
Reported by TaQ | October 22nd, 2008 @ 11:44 PM | in 2.x
Ok, I made some confusion trying to send this patch a long time ago and now I think I made it on the correct way.
I always find myself doing something like this:
Person.find(:all).collect {|person| [person.name,person.id]}
to make some HTML SELECT elements. As we already have Symbol#to_proc to help to select one model attribute, I made a way to select more than one attribute, creating Array#to_proc, so I can write the code above as
Person.find(:all).collect(&[:name,:id])
Comments and changes to this ticket
-
-
Pascal Ehlert October 28th, 2008 @ 05:23 AM
I get the idea, but imho that's what we have collection_select for.
Also, I would be careful with additional core extensions in general, I found myself numerous times trying to use AS stuff in regular ruby scripts.
to_proc is another neat feature of Ruby, but I'd rather leave it to the individual programmers what they do with it.
Sorry, but -1 from me, unless you can present a better use case ;-)
-
Michael Koziarski October 28th, 2008 @ 08:00 AM
- State changed from “new” to “wontfix”
This is pretty cool but I agree with Pascal, the only case you're citing is covered nicely with collection_select. Do you have any others in mind?
However I disagree with Pascal on the core extensions issue, extensions that are useful will continue to be added, and 'regular ruby' scripts can always just require active support :).
-
TaQ October 28th, 2008 @ 12:45 PM
Hi there!
About the core extensions, let me remind you that some things we can make here can be ported to Ruby itself, as Symbol#to_proc was on 1.9.x, check the Changelog file:
Sun Jun 11 04:38:20 2006 Nobuyoshi Nakada nobu@ruby-lang.org * object.c (sym_to_proc): imported Symbol#to_proc from ActiveSupport.
So, maybe Ruby scripts could not require ActiveSupport like Michael said but effectively merge the changes made here, so the danger to try to use features like Array#to_proc on regular Ruby on a near future will not be a problem as Pascal said. :-)
(Btw, I was trying to make a patch for MRI but really need to learn the C API right before doing that. :-p)
About collection_select, I think that creating the collection as shown here seems to me that is a ... let me say, "rubyish way" to make things there. But it's just my opinion, please!
I just thought about it as a way to get a collection of attributes, but I can be useful on some situations where Symbol#to_proc need to return more than one single value. Just don't have one in mind right now. :-)
-
Pascal Ehlert October 28th, 2008 @ 01:07 PM
Hi all,
apparently I need to clarify things a little. I did not at all intend to say we shouldn't extend the core!
Having the core classes open and extensible is one of the key concepts of Ruby and should be used whenever it makes sense.
The only point of my post was that we should be rather conservative with them, as they can also cause confusion, especially when they are accessible by their own operator (&)!
Furthermore, Array#to_proc seems much less intuitive than Symbol#to_proc, which is why I prefer to leave it up to the users what they use this feature for. When you extend it in AS, it is likely that Rails core will use it sooner or later (e.g. for collection_select internals) which makes it impossible to override it for the user!
Just my two cents, if you could give a few good use cases, it could of course make sense to add it!
-
-
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Michael Koziarski