#703 ✓wont_fix
Samuel Lebeau

Better $A behavior

Reported by Samuel Lebeau | June 5th, 2009 @ 07:31 PM | in 2.0

$A([1])                                         // => [1]
$A(null)                                        // => []
$A(undefined)                                   // => []
$A(true)                                        // => [true]
$A(false)                                       // => [false]
$A(1)                                           // => [1]
$A("foo")                                       // => ["foo"]
$A((function() { return arguments })(1, 2, 3))  // => [1, 2, 3]

It would help writing methods that takes either no argument, one argument or an
array of arguments.

i.e.

find({ conditions: "age > 18" });
find({ select: "firstName" });
find({ select: ["firstName", "lastName"] });

Then in find:

options.select = $A(options.select);

Comments and changes to this ticket

  • Samuel Lebeau

    Samuel Lebeau June 5th, 2009 @ 07:31 PM

    • State changed from “new” to “enhancement”
  • Tobie Langel

    Tobie Langel June 5th, 2009 @ 08:36 PM

    Isn't that already the case?

  • Tobie Langel
  • Tobie Langel

    Tobie Langel June 5th, 2009 @ 08:50 PM

    • State changed from “enhancement” to “wont_fix”

    Oops, sorry. Now I see your point.

    I don't really think that's possible or even desired. Remember, the $A method is based upon an object being iterable or having a toArray method. Hence:

    $A('foo');
    //-> ["f", "o", "o"]
    

    Your suggestion would either very badly break backwards compatibility (not only with strings, but also with custom objects having implemented a toArray method) or would be extremely inconsistant.

    Best implemented with a different API imho.

    Closing as wont_fix. Please feel free to start a discussion in the core mailing list about a different API.

  • Radoslav Stankov

    Radoslav Stankov June 5th, 2009 @ 08:53 PM

    I'm wondering why don't you implement this functionality in Array.from ? I check my codes for 3-4 project and I have never used it ( + in the code of the project were several open sourced Prototype based libs)
    The functionally would be really nice and using Array.from makes more sense for me to have it.

  • Tobie Langel

    Tobie Langel June 5th, 2009 @ 11:00 PM

    I'm wondering why don't you implement this functionality in Array.from

    Consistency.

    Array.from === $A;
    // -> true
    
    Hash.from === $H;
    // -> true
    
  • Radoslav Stankov

    Radoslav Stankov June 6th, 2009 @ 10:56 AM

    I understand, thanks for the explanation

  • Samuel Lebeau

    Samuel Lebeau June 6th, 2009 @ 01:15 PM

    Yes it clearly would have broken backward compatibility, that's why I was targetting 2.0.

    BTW, I think we should stop considering String as an Enumerable, and removing its toArray method just like in Ruby 1.9.

    In Ruby 1.8, String#each was enumerating over lines, and to_a was consistently returning the result of calling collect { |line| line }, but this was removed because it was semantically obscure.

    The fact that Prototype's String#each is yet different quite demonstrates the semantic blur IMHO.

  • Samuel Lebeau

    Samuel Lebeau June 8th, 2009 @ 11:14 PM

    Please note that, as String instances are "iterable" objects (with length and numeric properties), removing String#toArray wouldn't break $A current behavior.
    I'll start a thread on Core ML soon.

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 01:56 AM

    • Tag changed from a, array to section:lang

    [not-tagged:"array" tagged:"section:lang" bulk edit command]

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

The Prototype JavaScript library.

Shared Ticket Bins

Pages