Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66165
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_j1y+mz50d1x+YQJOmjw=6k9ra0k0T4SyAioG+Ea7tuoA@mail.gmail.com>
References: <CADqTB_j1y+mz50d1x+YQJOmjw=6k9ra0k0T4SyAioG+Ea7tuoA@mail.gmail.com>
Date: Fri, 22 Feb 2013 22:46:49 +0100
Message-ID: <CALtuQzAOVbHB72AL6_71rejVg_7qAfDOkAVBcvt2SqTGnJpaTg@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e010d867a31c9d404d657226b
Subject: Re: [PHP-DEV] rfc:trailing-comma-function-args
From: krebs.seb@gmail.com (Sebastian Krebs)

--089e010d867a31c9d404d657226b
Content-Type: text/plain; charset=ISO-8859-1

2013/2/22 Rasmus Schultz <rasmus@mindplay.dk>

> I've been thinking about this RCF for a while now:
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> It just doesn't seem necessary - the only time I've ever found something
> like this to be necessary, is when a function takes closures or other very
> long arguments, some of which are optional...


I must say, that I find this RFC completely useless. In my opinion when one
has such a long parameter list (or too long variable names),
that he must break the call onto several lines, the additional line in the
vcs' diff is the minor problem.


> but actually, writing this in
> a VCS-friendly way is already possible:
>
> $tree->traverse(
>     $tree
>     ,
>     function($node) {
>         // ...
>     }
> );
>
> ... version 2 ...
>
> $tree->traverse(
>     $tree
>     ,
>     function($node) {
>         // ...
>     }
>     ,
>     function($node) {
>         // ...
>     }
> );
>
> This actually comes out more legible, in my opinion.
>
> What really irks me about this patch, is that the trailing comma implies
> that another optional argument may exist - it really doesn't make the code
> more intuitive to read. The example on the page (using fopen) really isn't
> a realistic use-case - who would break a couple of simple arguments into
> individual lines like that?
>

/sign
Especially about the "implies, that another optional argument may exist":
One does not simply add arbitrary arguments to a function call. Except when
the function signature changes, but in this case (to repeat myself) the
additional diff-line is negligible.


>
> Just my two cents...
>

My too


>
> - Rasmus
>



-- 
github.com/KingCrunch

--089e010d867a31c9d404d657226b--