FAQ
This was floated in 2003 but had weak advocation and didn't seem to
come to a decisive resolution:

http://marc.info/?l=php-internals&m=106685833011253&w=2

Basically, the proposal is to modify the grammar to allow trailing
commas in function and method calls, so this becomes a parseable PHP
construct:

f(1, 2, 3,);

This patch applies only to function and method calls; it does not
apply to function or method definitions. It also does not allow the
degenerative case of "f(,)".

The real value of relaxing this rule is in nontrivial cases that span
across multiple lines:

sprintf(
'long example pattern with %d conversions: %s',
$several,
$conversions
);

This sort of construction makes the code more readable but also
exposes you to trailing-comma errors. You can easily introduce an
error either by removing the last parameter or by changing parameter
order. At least in my experience, these are relatively common syntax
errors, and ones that are easy to make when making edits that are
apparently minor. In the above example, I can remove the "%s"
conversion, remove the "$conversions" parameter, and inadvertently
introduce a syntax error because I have neglected to remove the comma
after "$several". Similarly, I can change the parameter order by
modifying the string and swapping $several for $conversions, but
introduce a syntax error by neglecting to move the comma.

In the current grammar, if a function or method call has been written
with parameters broken across multiple lines, adding or removing a
trailing parameter means you need to modify two lines of code instead
of one. This muddies and reduces the value of "blame" features in
revision control. It also makes diffs slightly larger and noisier,
which can make code reviews take a little longer since you have to
scan the line and make sure the only change is to the trailing comma.

The looser grammar is easier to use and more consistent: it's easier
to add, remove, or move parameters in an editor since you only need
to use line-oriented editor operations, and you don't need to
mentally distinguish between an array context and a parameter context.

In the original thread, Andi Gutmans explained that the decision to
allowing trailing commas in array() literals is supported by the
argument that it makes code generation easier. It seems like this
argument applies to trailing commas in function definitions just as
easily, and that the general ease-of-use arguments laid out above
provide at least as much value as this (particularly since this
specific code generation problem is solvable with implode()).

Andi also argued that this reduces readability and prevents assigning
semantics to a trailing comma in the future. While I agree that it
reduces readability in the "f(1, 2,)" case, I disagree that it
reduces readability in the less trivial multi-line case and it
greatly enhances "writeability". The possibility that the language
would ever benefit from assigning semantics here, while worth
considering, seems small. While my language architect credentials are
pretty weak, I can't think of any reasonable meaning. Many languages
accept trailing commas in data definitions (apparently including Java
(!) now[1]), and some (such as Python[2]) accept them in calls; in
all cases, the behavior is to ignore them. If PHP provided a
different semantic, this would be somewhat startling.

In general, trailing commas are increasingly an accepted part of the
grammars of modern languages. Beyond Java, Ruby and Python, Firefox
now accepts them in Javascript object definitions (which is surefire
way to tell that someone didn't test in IE). While they are more
often accepted in data definitions than calls, I don't see a strong
reason to distinguish between the cases.

This change has no impact on backward compatibility. It does makes it
slightly more difficult to write code which runs across multiple
versions of PHP. However, because it fails fast and explicitly, it's
an error which is easy to detect and resolve when you decide you want
to support more versions of PHP with your project. It's also
straightforward to write a script that uses the tokenizer to safely
and unambiguously remove trailing commas (I'd be happy to furnish
such a script if people think there's value in it and there's a
reasonable place to put it).

The diff in the original thread still seems correct, at least against
a relatively recent release -- I applied it to PHP 5.2.5 and ran the
tests, as well as verifying that the build could parse and execute
code which used trailing commas in calls.

So, what's the feeling on this? We're trying to weigh the merits of
rolling it into our stack at Facebook, but we'd feel a lot more
comfortable if it was present upstream.

Thanks,
Evan Priestley

[1] http://java.sun.com/docs/books/jls/second_edition/html/
arrays.doc.html#11358
[2] http://docs.python.org/ref/calls.html

Search Discussions

  • Christian Schneider at Jul 22, 2008 at 10:51 am

    Evan Priestley wrote:
    support more versions of PHP with your project. It's also
    straightforward to write a script that uses the tokenizer to safely and
    unambiguously remove trailing commas (I'd be happy to furnish such a
    The script "convertsyntax.php" at http://cschneid.com/php/ already
    provides this functionality so this is already covered :-)

    - Chris
  • Rodrigo Saboya at Jul 22, 2008 at 12:52 pm

    Evan Priestley escreveu:
    This was floated in 2003 but had weak advocation and didn't seem to come
    to a decisive resolution:

    http://marc.info/?l=php-internals&m=106685833011253&w=2

    Basically, the proposal is to modify the grammar to allow trailing
    commas in function and method calls, so this becomes a parseable PHP
    construct:

    f(1, 2, 3,);

    This patch applies only to function and method calls; it does not apply
    to function or method definitions. It also does not allow the
    degenerative case of "f(,)".

    The real value of relaxing this rule is in nontrivial cases that span
    across multiple lines:

    sprintf(
    'long example pattern with %d conversions: %s',
    $several,
    $conversions
    );
    You could just do this:

    sprintf(
    'long example pattern with %d conversions: %s'
    ,$several
    ,$conversions
    );

    I really don't see a great benefit here, and as you pointed out it would
    make code written with trailing commas incompatible with previous
    versions of PHP.

    --
    Rodrigo Saboya
  • Richard Quadling at Jul 22, 2008 at 2:35 pm
    2008/7/22 Rodrigo Saboya <rodrigo.saboya@bolsademulher.com>
    Evan Priestley escreveu:
    This was floated in 2003 but had weak advocation and didn't seem to come
    to a decisive resolution:

    http://marc.info/?l=php-internals&m=106685833011253&w=2

    Basically, the proposal is to modify the grammar to allow trailing commas
    in function and method calls, so this becomes a parseable PHP construct:

    f(1, 2, 3,);

    This patch applies only to function and method calls; it does not apply to
    function or method definitions. It also does not allow the degenerative case
    of "f(,)".

    The real value of relaxing this rule is in nontrivial cases that span
    across multiple lines:
    sprintf(
    'long example pattern with %d conversions: %s',
    $several,
    $conversions
    );
    You could just do this:

    sprintf(
    'long example pattern with %d conversions: %s'
    ,$several
    ,$conversions
    );

    I really don't see a great benefit here, and as you pointed out it would
    make code written with trailing commas incompatible with previous versions
    of PHP.

    --
    Rodrigo Saboya


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Just thinking of other languages that allow you to skip params simply by
    using commas. Whilst this isn't supported in PHP, allowing a trailing comma
    and skipped parameters could look quite interesting!

    foo(,,,,,,,);


    I must admit, I get stung with this in JS when I'm building AJAX option sets
    through Prototype for IE (I think like arrays in PHP which allow trailing
    ,), but I soon learned to do it properly.

    I don't see this as a huge advantage.

    Regards,

    Richard Quadling.
    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 21, '08 at 11:47p
activeJul 22, '08 at 2:35p
posts4
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase