# [VOTE] array_column() function

- Thread: https://externals.io/message/64870
- Original archive: https://news-web.php.net/php.internals/64870
- Started by Ben Ramsey on 2013-01-12T00:17:18+00:00
- Messages: 55
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/64870.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #64870 — Ben Ramsey — 2013-01-12T00:17:18+00:00

URL: https://externals.io/message/64870#64870

I've opened voting for the `array_column()` function RFC.

You can vote at https://wiki.php.net/rfc/array_column#voting

Regards,
Ben

---

## #64871 — Nikita Popov — 2013-01-12T00:21:10+00:00

URL: https://externals.io/message/64870#64871 · In reply to: #64870

> I've opened voting for the `array_column()` function RFC.
>
> You can vote at https://wiki.php.net/rfc/**array_column#voting<https://wiki.php.net/rfc/array_column#voting>
>
> Regards,
> Ben
>

Voting no, because - even though I like this feature in principle - I think
it's much better solved by introducing list comprehensions (which cover
this and many more cases in a consistent and elegant syntax), which is
something I have planned for 5.6.

Nikita

---

## #64872 — Matt Pelmear — 2013-01-12T00:36:12+00:00

URL: https://externals.io/message/64870#64872 · In reply to: #64870

> I've opened voting for the `array_column()` function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> Regards,
> Ben
>

+1

I can't vote, but I support this RFC.

This is much, much simpler to use and easier to implement than most 
other things I've been watching here recently (annotations, list 
comprehensions), and I work with multiple teams that would definitely 
benefit from this on a regular basis.

That said, I hate function aliases. Can't we have one or the other here, 
not both? (array_column() vs array_pluck())

-Matt

---

## #64873 — Nikita Popov — 2013-01-12T00:47:41+00:00

URL: https://externals.io/message/64870#64873 · In reply to: #64872

> That said, I hate function aliases. Can't we have one or the other here,
> not both? (array_column() vs array_pluck())
>

Agree fully on this part. If this is going to make it, then please,
*please* without aliases. `array_column()` is my preference here, because it
has some descriptive value, whereas I have no idea what "array pluck" is
supposed to be (and google doesn't give me much on it...)

Nikita

---

## #64874 — Arpad Ray — 2013-01-12T00:49:15+00:00

URL: https://externals.io/message/64870#64874 · In reply to: #64871

> Voting no, because - even though I like this feature in principle - I think
> it's much better solved by introducing list comprehensions (which cover
> this and many more cases in a consistent and elegant syntax), which is
> something I have planned for 5.6.


I'd love to see list/dict comprehensions in PHP :)

Arpad

---

## #64877 — Stas Malyshev — 2013-01-12T05:57:15+00:00

URL: https://externals.io/message/64870#64877 · In reply to: #64871

Hi!

> Voting no, because - even though I like this feature in principle - I think
> it's much better solved by introducing list comprehensions (which cover
> this and many more cases in a consistent and elegant syntax), which is
> something I have planned for 5.6.

This is a great illustration of different visions we have here. On one
hand, we have practical, immediate feature that covers a clear use case
and does not add any constructs or complexity to the core language and
services immediate need, covering several lines of frequently
encountered boilerplate code with one function.

On the other hand, we have a possibility to have in the future a
fashionable syntax, which is a bit better, more concise and "cool
looking" expression for what foreach already can do.

So, my "vision", for example, is that while there's nothing wrong with
"cool" language syntaxes and adding them, we should not reject simple
practical solutions for them. This is what was done in PHP for years,
and I think it is one of the reasons PHP is a great tool for the
programmer. Just trying to make my "vision" more clear :)
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #64878 — Anthony Ferrara — 2013-01-12T06:53:21+00:00

URL: https://externals.io/message/64870#64878 · In reply to: #64877

Stas,

This is a great illustration of different visions we have here. On one
> hand, we have practical, immediate feature that covers a clear use case
> and does not add any constructs or complexity to the core language and
> services immediate need, covering several lines of frequently
> encountered boilerplate code with one function.
>
> On the other hand, we have a possibility to have in the future a
> fashionable syntax, which is a bit better, more concise and "cool
> looking" expression for what foreach already can do.
>
> So, my "vision", for example, is that while there's nothing wrong with
> "cool" language syntaxes and adding them, we should not reject simple
> practical solutions for them. This is what was done in PHP for years,
> and I think it is one of the reasons PHP is a great tool for the
> programmer. Just trying to make my "vision" more clear :)
>

I definitely agree with you here. Voting against a library feature because
of a language future that's not even proposed yet is a bit... Odd...

With that said, I'm inclined to vote against this, but for a different
reason. (Note I said inclined, I haven't voted yet because my mind isn't
made up yet completely)...

I am concerned about library bloat. We already have 76 array functions:
http://us3.php.net/manual/en/ref.array.php

IMHO, a new function should be added in one of three cases:

1. It's hard to do in user-land

Meaning that it takes non-trivial code (30 to 40 lines, difficult error
handling, complex algorithms, etc). Considering that you can do the same
thing as this in 3 lines of user-land code without error handling, and 6
with error handling, I don't think it qualifies.

Contrast that to something like `sort()` which actually is a non-trivial
algorithm to do efficiently...

2. It's not performant to do in user-land.

Some things are just plain more efficient to do in C than PHP. Something
like a quicksort. But in this case the trivial PHP implementation should
run in O(n), just as C does. And since C is doing hashtable access for
everything, I can't see that this is going to be significantly more
efficient in C (at least for common sizes of arrays, say less than 10k
elements). If there are benchmarks that prove this point wrong, I'll
gladly concede it...

3. It's extremely common.

All other things aside, it would still belong in core IMHO if it's an
extremely common need. That way we can help common implementation problems
and make life easier. Pretty self explanatory.

From what I can see this new function doesn't fit any of those three to a
significant enough extent. All three are definitely subjective, but I'm
leaning towards a no vote because I just don't feel there's enough
justification for the new function when weighted against the bloat factor...

My $0.02... Thoughts?

Anthony

---

## #64879 — Kris Craig — 2013-01-12T06:59:15+00:00

URL: https://externals.io/message/64870#64879 · In reply to: #64878

On Fri, Jan 11, 2013 at 10:53 PM, Anthony Ferrara <ircmaxell@gmail.com>wrote:

> Stas,
>
> This is a great illustration of different visions we have here. On one
> > […]
>
> I definitely agree with you here. Voting against a library feature because
> of a language future that's not even proposed yet is a bit... Odd...
>
> With that said, I'm inclined to vote against this, but for a different
> reason. (Note I said inclined, I haven't voted yet because my mind isn't
> made up yet completely)...
>
> I am concerned about library bloat. We already have 76 array functions:
> http://us3.php.net/manual/en/ref.array.php
>
> IMHO, a new function should be added in one of three cases:
>
> 1. It's hard to do in user-land
>
> Meaning that it takes non-trivial code (30 to 40 lines, difficult error
> handling, complex algorithms, etc). Considering that you can do the same
> thing as this in 3 lines of user-land code without error handling, and 6
> with error handling, I don't think it qualifies.
>
> Contrast that to something like `sort()` which actually is a non-trivial
> algorithm to do efficiently...
>
> 2. It's not performant to do in user-land.
>
> Some things are just plain more efficient to do in C than PHP. Something
> like a quicksort. But in this case the trivial PHP implementation should
> run in O(n), just as C does. And since C is doing hashtable access for
> everything, I can't see that this is going to be significantly more
> efficient in C (at least for common sizes of arrays, say less than 10k
> elements). If there are benchmarks that prove this point wrong, I'll
> gladly concede it...
>
> 3. It's extremely common.
>
> All other things aside, it would still belong in core IMHO if it's an
> extremely common need. That way we can help common implementation problems
> and make life easier. Pretty self explanatory.
>
> From what I can see this new function doesn't fit any of those three to a
> significant enough extent. All three are definitely subjective, but I'm
> leaning towards a no vote because I just don't feel there's enough
> justification for the new function when weighted against the bloat
> factor...
>
> My $0.02... Thoughts?
>
> Anthony
>

What do you believe is the biggest loss incurred by adding a function that
is useful but does not fit any of the three criteria you listed?
 Personally, I can't really think of one.  I think it's more important to
focus on consistency between functions (arguments order, etc) and clear
documentation (which could be more difficult with a ton of array-related
functions to scroll through, but that could be mitigated by organizing them
into alphabetized subgroups).

--Kris

---

## #64880 — Levi Morrison — 2013-01-12T08:04:33+00:00

URL: https://externals.io/message/64870#64880 · In reply to: #64879

The real problem here (in my opinion) is that `array_filter` does not
pass the key information to the callback. If you could do that, you
could select columns that way.

---

## #64881 — Nikita Popov — 2013-01-12T11:30:11+00:00

URL: https://externals.io/message/64870#64881 · In reply to: #64877

On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > […]
> think
> > […]
>
> This is a great illustration of different visions we have here. On one
> hand, we have practical, immediate feature that covers a clear use case
> and does not add any constructs or complexity to the core language and
> services immediate need, covering several lines of frequently
> encountered boilerplate code with one function.
>
> On the other hand, we have a possibility to have in the future a
> fashionable syntax, which is a bit better, more concise and "cool
> looking" expression for what foreach already can do.
>

Stas, I think you are misrepresenting this a bit. It's not about adding
something "cool looking", it's about adding a feature that solves *this and
many more* problems in a consistent way. A way that does *not* require to
add a new function for every single array manipulation.

I know that not everyone agrees with that philosophy, but I personally
don't like to add new features that can be easily covered by more general
solutions, or features that just represent a hack because the more general
solution isn't implemented yet. This is also the reason why I don't
particularly like your argument skipping proposal, because it's just a hack
around the lack of named arguments. The thing with the argument skipping
proposal is though that the alternative (named args) is pretty hard to
implement and we might not actually get them any time soon. Here it is
different as list comprehensions are more or less a triviality.

That's why I think that this is not necessary. It will be hopefully
properly handled in the future and until then this function is trivial
enough to just write it yourself. I don't see how we need yet another
array_ function for it.

But hey, just my opinion, not everyone has to agree with this :)

Thanks,
Nikita

---

## #64882 — Peter Cowburn — 2013-01-12T15:14:04+00:00

URL: https://externals.io/message/64870#64882 · In reply to: #64870

> I've opened voting for the `array_column()` function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> Regards,
> Ben
>

The "Status" for this RFC is still "Under discussion" and on the RFC
listing page it is the same. Is not changing those two things simply
an oversight?

---

## #64883 — Derick Rethans — 2013-01-12T15:19:18+00:00

URL: https://externals.io/message/64870#64883 · In reply to: #64870

> I've opened voting for the `array_column()` function RFC.
> 
> You can vote at https://wiki.php.net/rfc/array_column#voting

I'm liking this, why start with an function alias already when 
introducing a new feature?

cheers,
Derick

---

## #64884 — Derick Rethans — 2013-01-12T15:22:32+00:00

URL: https://externals.io/message/64870#64884 · In reply to: #64877

> > […]
> 
> This is a great illustration of different visions we have here. On one
> hand, we have practical, immediate feature that covers a clear use case
> and does not add any constructs or complexity to the core language and
> services immediate need, covering several lines of frequently
> encountered boilerplate code with one function.
> 
> On the other hand, we have a possibility to have in the future a
> fashionable syntax, which is a bit better, more concise and "cool
> looking" expression for what foreach already can do.
> 
> So, my "vision", for example, is that while there's nothing wrong with
> "cool" language syntaxes and adding them, we should not reject simple
> practical solutions for them. This is what was done in PHP for years,
> and I think it is one of the reasons PHP is a great tool for the
> programmer. Just trying to make my "vision" more clear :)

I wholeheartly agree with that!

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #64885 — Ben Ramsey — 2013-01-12T15:28:46+00:00

URL: https://externals.io/message/64870#64885 · In reply to: #64882

> The "Status" for this RFC is still "Under discussion" and on the RFC
> listing page it is the same. Is not changing those two things simply
> an oversight?
>

It was an oversight. I have corrected it in both places.

---

## #64886 — Ben Ramsey — 2013-01-12T15:34:55+00:00

URL: https://externals.io/message/64870#64886 · In reply to: #64883

> I'm liking this, why start with an function alias already when
> introducing a new feature?

I figured this would be a frequent question, and I was right. :-)

In earlier discussions (June 2012), when I first introduced 
 `array_column()`, much of the discussion revolved around the name and not 
the functionality. I agreed with arguments for `array_column()` and 
arguments for array_pluck(), so I added an alias.

Here's why I think the alias should be considered:

1) Userland PHP developers instantly recognize `array_column()`. It's 
self-descriptive, and they know what it means.

2) Developers coming from other languages (Ruby, JavaScript, etc.) will 
instantly recognize array_pluck(). It's what they'll be looking for to 
do the same thing, but they won't be looking for `array_column()`.

-Ben

---

## #64887 — Derick Rethans — 2013-01-12T15:54:37+00:00

URL: https://externals.io/message/64870#64887 · In reply to: #64881

> On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> 
> > […]
> 
> Stas, I think you are misrepresenting this a bit. It's not about 
> adding something "cool looking", it's about adding a feature that 
> solves *this and many more* problems in a consistent way. A way that 
> does *not* require to add a new function for every single array 
> manipulation.
> 
> I know that not everyone agrees with that philosophy, but I personally 
> don't like to add new features that can be easily covered by more 
> general solutions, or features that just represent a hack because the 
> more general solution isn't implemented yet.

By more general you mean extra special new OO constructs? Sorry, but PHP 
should also be useable by non-CS majors. And so what we have 76 (soon 
77!) array functions?

> This is also the reason why I don't particularly like your argument 
> skipping proposal, because it's just a hack around the lack of named 
> arguments.

Argument skipping is a language construct, this just adds a new function 
to the 2000 we already have. Quite a different matter.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #64888 — Clint Priest — 2013-01-12T15:55:00+00:00

URL: https://externals.io/message/64870#64888 · In reply to: #64886

My .02 cents here...

I'm used to array_pluck(), even when I first saw it I was like WTH is 
that?  When you read the description though, 'plucking' is a verb which 
describes the action the function is taking, while column is a noun and 
does not describe the action the function is taking.

In fact I have my own userland array_pluck() function.

Ergo, `array_column()` doesn't make sense, array_get_column() might make 
sense, while array_pluck() makes sense.

I'm fine with an alias or either one really, just pointing out the logic 
of "pluck."

-Clint


> 
> > […]
>
> I figured this would be a frequent question, and I was right. :-)
>
> In earlier discussions (June 2012), when I first introduced 
> `array_column()`, much of the discussion revolved around the name and 
> not the functionality. I agreed with arguments for `array_column()` and 
> arguments for array_pluck(), so I added an alias.
>
> Here's why I think the alias should be considered:
>
> 1) Userland PHP developers instantly recognize `array_column()`. It's 
> self-descriptive, and they know what it means.
>
> 2) Developers coming from other languages (Ruby, JavaScript, etc.) 
> will instantly recognize array_pluck(). It's what they'll be looking 
> for to do the same thing, but they won't be looking for `array_column()`.
>
> -Ben
>

-- 
-Clint

---

## #64891 — Thomas Hruska — 2013-01-12T16:12:09+00:00

URL: https://externals.io/message/64870#64891 · In reply to: #64878

> > […]
> significant enough extent. All three are definitely subjective, but I'm
> leaning towards a no vote because I just don't feel there's enough
> justification for the new function when weighted against the bloat factor...
>
> My $0.02... Thoughts?
>
> Anthony

I can see a use-case for this but the PDO relationship is a poor reason 
for having it.  The whole PDO thing threw me off such that I was in the 
same boat as Anthony with the same thoughts.  Contrived examples aren't 
helpful for passing a RFC.  Here is a more reasonable example:

echo implode(", ", array_column($myarray, 2));

It saves constructing a separate array or writing my own function in PHP 
userland that comes with the risk of naming conflicts.  `array_column()` 
is a handy shortcut to a process.  I've not thought about writing a PHP 
userland function for this before because it generally only takes a 
couple of lines of code.  This formalizes that process and simplifies code.

It isn't a function I'll necessarily use every day, but the above 
example is more useful and will speak to more developers than the PDO 
example will.

I have a separate recommendation that could eliminate the need for the 
third optional parameter of `array_column()`, but I'll start another 
thread on this list for it.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you might find useful.

http://cubiclesoft.com/

---

## #64892 — Peter Cowburn — 2013-01-12T16:13:26+00:00

URL: https://externals.io/message/64870#64892 · In reply to: #64870

> I've opened voting for the `array_column()` function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>

I like the idea of this function, but have a few minor questions re.
the current implementation.

1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
want this to be part of 5.3? The RFC (in particular the vote question)
does not make it clear where/when you want this to be added.

2. The $columnKey argument "may be the 0-indexed number of the column
you wish to retrieve, or it may be the string key name for an
associative array."

When the nested arrays use numeric indices and the function is called
with a number, then this argument is not "the 0-indexed number of the
column" but rather the integer key (i.e., the $columnKey is always
specifying the key, regardless of integer or string).  Could the
description be updated to reflect that, if it is indeed the desired
behaviour?  Also, when the nested arrays are non-0-indexed should we
be able to somehow specify the column (rather than the key)? I have no
answer of my own for that last question!

3. It is not documented what happens when the $columnKey and/or
$indexKey are not present in the nested array, could this be added?
The current implementation appears to not include an item in the
resulting array if $columnKey is not present. If $columnKey is present
but $indexKey is not, a 0-based index is used in the current
implementation.

4. An example of what happens when the resulting array has overlapping
keys would not go amiss (though the behaviour is obvious).

5. Regarding the alias, so long as we clearly mention the word "pluck"
(or "array_pluck") on the documentation page, folks coming from other
languages should be able to find our implementation.  I'm not sure we
really need it as an actual alias, but have no strong opinion one way
or the other.

Overall, I'm liking this simple addition to the array library.

---

## #64893 — Levi Morrison — 2013-01-12T16:17:20+00:00

URL: https://externals.io/message/64870#64893 · In reply to: #64892

> 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
> want this to be part of 5.3? The RFC (in particular the vote question)
> does not make it clear where/when you want this to be added.

Please, this is not a bug or security fix. It does not belong in 5.3.

---

## #64894 — Nikita Popov — 2013-01-12T16:24:33+00:00

URL: https://externals.io/message/64870#64894 · In reply to: #64887

> > […]
>
> By more general you mean extra special new OO constructs? Sorry, but PHP
> should also be useable by non-CS majors. And so what we have 76 (soon
> 77!) array functions?
>

List comprehensions are in no way related to OO. At least no way I know
off. But in any case:

I apologize for what I wrote in the first mail in the thread. It was not
constructive to this discussion, because it only contained half of my
reasoning and I only mentioned the more controversial part.

What I should have said is this: I think that this is a very simple
function that can be easily implemented in userland and I just don't see
sufficient need or implementational advantages for it to be part of core
(see also Anthony's response). The note on list comprehensions should only
be relevant insofar that they would make this function even *less* useless
in the future.

Again, sorry for hijacking this thread.
Nikita

---

## #64896 — Ben Ramsey — 2013-01-12T16:41:29+00:00

URL: https://externals.io/message/64870#64896 · In reply to: #64893

> > […]
>
> Please, this is not a bug or security fix. It does not belong in 5.3.
>

I must have misread the Git Workflow page of the wiki, which states:

"A patch will be applied to the oldest possible branch. If the Release 
Manager of 5.3 accepts the change, commit it to the 5.3 branch. We will 
use regular merging between the release branches."

I can submit a new pull request against the master branch, if that's 
acceptable. This is intended for 5.5.

-Ben

---

## #64899 — Ben Ramsey — 2013-01-12T17:38:29+00:00

URL: https://externals.io/message/64870#64899 · In reply to: #64892

> 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
> want this to be part of 5.3? The RFC (in particular the vote question)
> does not make it clear where/when you want this to be added.

I mentioned this in another response on this thread. I was just 
following instructions from the wiki, but I can issue another pull 
request against master or some other branch.

This is intended for 5.5.

> 2. The $columnKey argument "may be the 0-indexed number of the column
> you wish to retrieve, or it may be the string key name for an
> associative array."
>
> When the nested arrays use numeric indices and the function is called
> with a number, then this argument is not "the 0-indexed number of the
> column" but rather the integer key (i.e., the $columnKey is always
> specifying the key, regardless of integer or string).  Could the
> description be updated to reflect that, if it is indeed the desired

I've updated the RFC on the wiki to include your suggestions.

> behaviour?  Also, when the nested arrays are non-0-indexed should we
> be able to somehow specify the column (rather than the key)? I have no
> answer of my own for that last question!

I'm not quite sure what you're asking here. Do you mean specifying 
something like the numeric column position, rather than the string key?

>
> 3. It is not documented what happens when the $columnKey and/or
> $indexKey are not present in the nested array, could this be added?
> The current implementation appears to not include an item in the
> resulting array if $columnKey is not present. If $columnKey is present
> but $indexKey is not, a 0-based index is used in the current
> implementation.

I've added Example #4 to illustrate this.

> 4. An example of what happens when the resulting array has overlapping
> keys would not go amiss (though the behaviour is obvious).

I've added Example #5 for this.

> 5. Regarding the alias, so long as we clearly mention the word "pluck"
> (or "array_pluck") on the documentation page, folks coming from other
> languages should be able to find our implementation.  I'm not sure we
> really need it as an actual alias, but have no strong opinion one way
> or the other.

My opinion on this isn't strong, either. I've already given my rationale 
in another post to this thread, but if most people want the alias 
removed, I'm okay with that.

> Overall, I'm liking this simple addition to the array library.

---

## #64904 — Lars Strojny — 2013-01-12T19:48:59+00:00

URL: https://externals.io/message/64870#64904 · In reply to: #64870

Hi Ben,

Am 12.01.2013 um 01:17 schrieb Ben Ramsey <ramsey@php.net>:

> I've opened voting for the `array_column()` function RFC.
> 
> You can vote at https://wiki.php.net/rfc/array_column#voting

I voted yes, but I prefer to call it just array_pluck (no aliases). It’s what underscore.js calls it and my own pet project functional-php calls it Functional\pluck() as well. What do you think?

cu,
Lars

---

## #64908 — Matt Pelmear — 2013-01-12T20:22:32+00:00

URL: https://externals.io/message/64870#64908 · In reply to: #64886

Hi,


>
> 2) Developers coming from other languages (Ruby, JavaScript, etc.) 
> will instantly recognize array_pluck(). It's what they'll be looking 
> for to do the same thing, but they won't be looking for `array_column()`.
>
> -Ben
>

When I have to write JavaScript (for example), I end up doing google 
searches like "javascript php array_keys" and always find what I'm 
looking for without a problem. I really think the alias just adds confusion.

Clint's argument for "pluck" being a verb and "column" being a noun 
makes some sense to me, however "plucking" would imply, to me, that the 
data is being removed from the source, as opposed to copied from it. As 
google says: "Pluck: Take hold of (something) and quickly remove it from 
its place".

Also, "array_column" is certainly consistent with other function names 
in PHP (array_keys(), values(), `key()`, etc.), which also refer to a set 
of data within the array data structure, whereas "pluck" sounds very 
much like a carryover from Ruby and Prototype.


-Matt

---

Next page: https://externals.io/message/64870.md?page=2