[RFC] Allow trailing comma in function call argument lists

Derick Rethans

13 years ago

On Tue, 19 Feb 2013, Sara Golemon wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args

+1

cheers,
Derick

Pierre Joye

13 years ago

On Tue, Feb 19, 2013 at 1:06 PM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args

looks good and consistent enough, you have my vote :)

--
Pierre

@pierrejoye

Patrick ALLAERT

13 years ago

2013/2/19 Sara Golemon <pollita@php.net>:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

I'm all for it! Waiting for the official voting...

Kingsquare.nl - Robin Speekenbrink

13 years ago

Just a question from one of the lingering listeners: would this change also
ease the `skipping` of default values for parameters? (as discussed for RFC
https://wiki.php.net/rfc/skipparams)

That way it would be consistent with this RFC and the list() construct ?

With regards,

Robin Speekenbrink

2013/2/19 Sara Golemon <pollita@php.net>

Sara Golemon

13 years ago

On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
<robin@kingsquare.nl> wrote:

> Just a question from one of the lingering listeners: would this change also
> ease the `skipping` of default values for parameters? (as discussed for RFC
> https://wiki.php.net/rfc/skipparams)
>
> That way it would be consistent with this RFC and the list() construct ?
>

It's orthogonal to skipparams.  It'd neither help nor hurt based on
the recommendations of that RFC.

With regard to list(), it already supports expressions like this:
list($x,) = array(123); so nothing more needs to be done for it and
it's not at odds with either of these RFCs.

-Sara

Kingsquare.nl - Robin Speekenbrink

13 years ago

Sara,

I wasnt commenting that this RFC was different, just in agreement that this
syntax is _more_ in line with the list() construct (which then might
reflect the skipparams rfc))
If i wasnt clear: from a user point of view: i am all for this RFC ;)

Met vriendelijke groet,

Robin Speekenbrink
Kingsquare BV


2013/2/19 Sara Golemon <pollita@php.net>

Will Fitch

13 years ago

On Feb 19, 2013, at 8:00 AM, Sara Golemon <pollita@php.net> wrote:

> On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
> <robin@kingsquare.nl> wrote:
>> Just a question from one of the lingering listeners: would this change also
>> ease the `skipping` of default values for parameters? (as discussed for RFC
>> https://wiki.php.net/rfc/skipparams)
>>
>> That way it would be consistent with this RFC and the list() construct ?
>>
> It's orthogonal to skipparams.  It'd neither help nor hurt based on
> the recommendations of that RFC.
>
> With regard to list(), it already supports expressions like this:
> list($x,) = array(123); so nothing more needs to be done for it and
> it's not at odds with either of these RFCs.

I would vote +1 on this solely for the sake of consistency.  I've never liked the idea behind the parser's actions on constructs (list, array).

Marcello Duarte

13 years ago

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Please feedback,

--
Marcello Duarte

Derick Rethans

13 years ago

On Tue, 19 Feb 2013, Marcello Duarte wrote:

> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function

I'd be really reluctant to add this -- it's yet another (superfluous)
syntactical sugar, there is no patch, and how does this work with bound
variables (use keyword)?

cheers,
Derick

Marcello Duarte

13 years ago

Thanks for the feedback. I get most people here don't appreciate the value of the feature.

I can understand that If you haven't tried to write a tool like capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see much value in implementing such things.

On 19 Feb 2013, at 13:19, Derick Rethans wrote:

> On Tue, 19 Feb 2013, Marcello Duarte wrote:
>
>> Inspired by Sara, here is another RFC, I finally got around to draft:
>>
>> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> I'd be really reluctant to add this -- it's yet another (superfluous)
> syntactical sugar, there is no patch, and how does this work with bound
> variables (use keyword)?

I added an example with the use keyword.

What is superfluous for is useful for other users. It would be useful building DSL. At my company we use loads of ruby tools for deploying, provisioning, etc. just because of the DSL they provide. The array short syntax was great news. Adding a short syntax for closures would make it possible to write such scripts in PHP – where the syntax would not stand on its way.

On 19 Feb 2013, at 13:28, Patrick ALLAERT wrote:

>> BC break detected:
>>
>> <?php
>> {
>>    echo "foo\n";
>>    return "bar";
>> };
>>
>> echo "baz\n";
>> return 42;
>> ?>

I am actually more concerned with Patrick's feedback regarding BC. I can't think of a solution for this right now.

> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Marcello Duarte

Lars Strojny

13 years ago

Hi Marcello,

Am 19.02.2013 um 14:51 schrieb Marcello Duarte <mduarte@inviqa.com>:

> Thanks for the feedback. I get most people here don't appreciate the value of the feature.
>
> I can understand that If you haven't tried to write a tool like capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see much value in implementing such things.
>
> On 19 Feb 2013, at 13:19, Derick Rethans wrote:
>> On Tue, 19 Feb 2013, Marcello Duarte wrote:
>>
>>> Inspired by Sara, here is another RFC, I finally got around to draft:
>>>
>>> https://wiki.php.net/rfc/short-syntax-for-anonymous-function

I don’t like the syntax, but the proposal in general. If you compare PHPs syntax to various others, it is indeed clumsy.

Python:
map(lambda v: v * 2, [1, 2, 3])

Ruby:
[1, 2, 3].map{|x| x * 2}

Scala:
List(1, 2, 3).map((x: Int) => x * 2)

PHP:
array_map(function ($x) {return $x * 2;}, [1, 2, 3]);

So even a statically typed language like Scala is shorter and better to read. A good improvement would be implicit return and getting rid of the function keyword.

array_map(($x): $x * 2;, [1, 2, 3]);

But this RFC should come with a patch, otherwise we are discussing things that aren’t necessarily easy to implement.

cu,
Lars

Leigh

13 years ago

>
>
> I can understand that If you haven't tried to write a tool like
> capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see
> much value in implementing such things.
>
>

Your RFC doesn't go to great lengths to explain the value either. Pretend
the reader has no experience with any of those tools you mention, pretend
the only language they know is PHP, please explain where the value for this
syntax is in PHP?

I find the existing syntax easy to understand. I find the proposed syntax
disproportionally difficult and unintuitive in relation to any benefit it
is supposed to give.

> What is superfluous for is useful for other users. It would be useful
> building DSL. At my company we use loads of ruby tools for deploying,
> provisioning, etc. just because of the DSL they provide. The array short
> syntax was great news. Adding a short syntax for closures would make it
> possible to write such scripts in PHP – where the syntax would not stand on
> its way.
>
>

<insert PHP is not Ruby rhetoric>

If Ruby is the right tool for the job, and PHP is not the right tool for
the job, the answer to which language to use seems obvious right?

I disagree wholeheartedly that this proposed syntax would make code in any
way more readable, or maintainable.

Arvids Godjuks

13 years ago

I also don't like the RFC proposed syntax. I have to say that I don't
really like those short magic-like syntax things in in other languages too.
If you work with them on the day-to-day basis and tools are built around
those concepts - it's one thing. In PHP syntax is mostly self-explanatory
and for the most part there is only one way to do it (or the differences in
syntax have their own uses - like for () {} is used in code and  for ():
endfor; is good for templates).

I like the current $x = function () {}. It's the same in JavaScript (and
because most of us use jQuery - we use it a lot) and realistically I don't
type it - IDE does auto-complete for me.

P.S. I want to tell all those syntax enhancement guys - don't push
syntax-sugar stuff into PHP for the sake of shorter syntax. First, for the
most part it looks alien in PHP. Second - it really depends on the
preception - I for example hate Ruby syntax, it's crap and unreadable -
this just illustrated that's one mans beauty is other mans ugly. PHP syntax
maybe not the most pretty out there, but it is sure as hell easy to read
even if coder makes a mess of it. I saw the opinion on the internet that
PHP is a scripted version of C in the sense of their positioning and usage.
And I totally agree with it, and I want it to stay that way. PHP should not
be the pretty one, or be on the feature edge. PHP needs to just walk with
time and adopt the good stuff fully integrating into itself, not just
patching the core and adding some half-weird syntax that just doesn't
really fit PHP.
You also have to remember that PHP is a WEB development script language,
not general purpose script language like Ruby or Python. Not all features,
that are good in general purpose languages, are good for WEB language. Some
of those features may bring performance hits that are not worth it.

My 0.02$,
Arvids.

Marcello Duarte

13 years ago

On 19 Feb 2013, at 14:16, Leigh wrote:

>>
>>
>> I can understand that If you haven't tried to write a tool like
>> capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see
>> much value in implementing such things.
>>
>>
> Your RFC doesn't go to great lengths to explain the value either. Pretend
> the reader has no experience with any of those tools you mention, pretend
> the only language they know is PHP, please explain where the value for this
> syntax is in PHP?

Very good feedback. Very much appreciated. I will see if I can expand on what I have that. Thank you.

> I find the existing syntax easy to understand. I find the proposed syntax
> disproportionally difficult and unintuitive in relation to any benefit it
> is supposed to give.
>
>
>> What is superfluous for is useful for other users. It would be useful
>> building DSL. At my company we use loads of ruby tools for deploying,
>> provisioning, etc. just because of the DSL they provide. The array short
>> syntax was great news. Adding a short syntax for closures would make it
>> possible to write such scripts in PHP – where the syntax would not stand on
>> its way.
>>
>>
> <insert PHP is not Ruby rhetoric>
>
> If Ruby is the right tool for the job, and PHP is not the right tool for
> the job, the answer to which language to use seems obvious right?

I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application.

> I disagree wholeheartedly that this proposed syntax would make code in any
> way more readable, or maintainable.

Please understand that there is a difference between code you write and other people maintain, and code you write for other people to use. The purpose of this feature is focused on the later, to allow the construction of DSLs, so users of your code can focus on the task at hand.

--
Marcello Duarte

Leigh

13 years ago

On 19 February 2013 16:46, Marcello Duarte <mduarte@inviqa.com> wrote:

> I find that more and more my developers have to learn ruby just to be able
> to work in our projects. We are one of the largest PHP shops in Europe and
> even the proprietary tools we are writing for DevOps stuff we are writing
> in Ruby. This small syntax arrangement would make it possible to write DSLs
> in PHP. The result is that I can have my PHP developers focusing on one
> language only and get the job done. The problem of the web is a bit more
> complex now, if you look on all you need to develop and deploy a large PHP
> application.
>

That is one of the choices you made for your projects. You looked at what
was available, and decided that Ruby was the best choice for the task at
hand.

While I agree it's unfortunate that your developers to have to waste their
time learning Ruby, when they could be doing more productive things, that
doesn't mean it's a good idea to try and retrofit some evil syntax into PHP
"just for you", no matter how large an organisation you are.

By the way, PHP is open source, feel free to make the parser do whatever
you want.



On 19 February 2013 16:40, Levi Morrison <morrison.levi@gmail.com> wrote:

> > Say we agree on the syntax above
> >> ($n) |$m| => $m * $n;
> > What happens when my one liner function needs to do one more operation
> > like checking the value of $n before multiplication?
>
> As I stated before suggesting the syntax: It's only meant for a single
> expression. It's purposefully NOT intended to cover multiple
> expressions.  In that case the current (verbose) syntax is better for
> all criteria I care about. Additionally, neither Python nor Dart
> allows multiple expressions in their short-syntax functions.
>

I prefer this. In this case (imho), a simplified syntax *should* go hand in
hand with simplified functionality. If PHP is to adopt such a syntax I'd
much prefer it takes the single expression approach. This does achieve the
goals of easy readability and maintenance because you know the expression
is bound by certain limitations.

Marcello Duarte

13 years ago

On 19 Feb 2013, at 17:32, Leigh wrote:

>
> On 19 February 2013 16:46, Marcello Duarte <mduarte@inviqa.com> wrote:
> I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application.
>
> That is one of the choices you made for your projects. You looked at what was available, and decided that Ruby was the best choice for the task at hand.
>
> While I agree it's unfortunate that your developers to have to waste their time learning Ruby, when they could be doing more productive things, that doesn't mean it's a good idea to try and retrofit some evil syntax into PHP "just for you", no matter how large an organisation you are.

I am curious: "evil syntax"? I am not attached to the syntax I have described. I am open to discuss the syntax. It would be good with using the callable as last argument converted into a block for DSLs. I don't think this is evil, but I don't want to fall into a personal taste debate. I want something I can use.

And "just for you" is also inaccurate. You will find that the technologies I've been referring to are becoming the tools you will use for DevOps, etc... tasks. Do you guys listen to people outside of internals? It would be good to have a feedback mechanism that actually involve PHP developers in real world projects. I take that if you are coding with other languages like C, all the time, that you may loose contact with the way things are done.

> By the way, PHP is open source, feel free to make the parser do whatever you want.
>
>
>
> On 19 February 2013 16:40, Levi Morrison <morrison.levi@gmail.com> wrote:
> > Say we agree on the syntax above
> >> ($n) |$m| => $m * $n;
> > What happens when my one liner function needs to do one more operation
> > like checking the value of $n before multiplication?
>
> As I stated before suggesting the syntax: It's only meant for a single
> expression. It's purposefully NOT intended to cover multiple
> expressions.  In that case the current (verbose) syntax is better for
> all criteria I care about. Additionally, neither Python nor Dart
> allows multiple expressions in their short-syntax functions.
>
> I prefer this. In this case (imho), a simplified syntax *should* go hand in hand with simplified functionality. If PHP is to adopt such a syntax I'd much prefer it takes the single expression approach. This does achieve the goals of easy readability and maintenance because you know the expression is bound by certain limitations.
>

--
Marcello Duarte
Head of Training

Inviqa
enterprise open source

e-mail: marcello@inviqa.com
mobile: +44 78 3316 8193

phone: +44 20 3179 9555
twitter: @_md @Inviqa
inviqa.com

Disclaimer
This email and any attachments may be confidential and are intended solely for the use of the addressee. Any views or opinions expressed are those of the author and may not represent those of Inviqa. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

Levi Morrison

13 years ago

Please reply to the list in plain text, thank you!

Marco Pivetta

13 years ago

@Marcello: actually, I am also of the idea that there's no real additional
value in such a syntax...

Since I'm using ZF2 (yeah, that framework that converts array to
applications) I am kinda used to have dozens of `function () {}` closures
for service factories: so far no problems with it.

As stated before, it spares 9 chars while the end developer (devops or
whoever coding instead of of the devops) loses a lot of readability that is
not really such a big problem.

Also, as it is for DSLs, you could always use a parser to handle this kind
of thing in your own domain.

What exactly is the limit that you see when applying the more verbose
`function () {}` syntax? I am just wondering since moving to `{}` will
still not make this portable to any platform except PHP itself.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Christopher Jones

13 years ago

On 02/19/2013 09:45 AM, Marcello Duarte wrote:

> And "just for you" is also inaccurate. You will find that the
> technologies I've been referring to are becoming the tools you will
> use for DevOps, etc... tasks. Do you guys listen to people outside
> of internals? It would be good to have a feedback mechanism that
> actually involve PHP developers in real world projects. I take that
> if you are coding with other languages like C, all the time, that
> you may loose contact with the way things are done.

I should add "don't flame existing developers" to
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
(Note that "In summary" paragraph at the end).

Without getting into the merits of the syntax change, I will say that
the RFC is missing a lot: who will write the patch, where are examples
of syntax in other languages, where is the clear comparison with
existing PHP syntax, what are the quantifiable benefits.

Don't forget to update the RFC with the mail list comments, e.g. the
BC issue.  Even if your RFC is rejected, it will help future PHP
development if the RFC contains a summary of mail list discussions.

Chris

--
christopher.jones@oracle.com  http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

Anthony Ferrara

13 years ago

Marcello,

On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte <mduarte@inviqa.com> wrote:

> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
> --
> Marcello Duarte
>
>

I like the concept. I dislike the syntax. It looks too much like a JSON
object declaration, and it feels like it should be returning an object
instead of a closure/anonymous function. Additionally, I don't like that
it's also a closure. Short functions like this should be for simple
functions...

Perhaps:

lambda $x: trim($x);

$x: trim($x);

Or something similar...

Anthony

Paul Dragoonis

13 years ago

I also am not in favour of the syntax, it's too short and quirky. I'm
honestly fine with 'function()' it's very explicit


On Tue, Feb 19, 2013 at 1:20 PM, Anthony Ferrara <ircmaxell@gmail.com>wrote:

Michael Wallner

13 years ago

On 19 February 2013 13:57, Marcello Duarte <mduarte@inviqa.com> wrote:

> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
>
>

Duh, I don't think function(){} is long.

--
Regards,
Mike

Patrick ALLAERT

13 years ago

2013/2/19 Marcello Duarte <mduarte@inviqa.com>:

> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
> --
> Marcello Duarte

BC break detected:

<?php
{
echo "foo\n";
return "bar";
};

echo "baz\n";
return 42;
?>

The {} would probably be a closure that is not assigned to anything
while the current behaviour is to print "foo" and exit while returning
"bar".

-1 since it only saves 10 chars ("function()") without real added value.

Bob Weinand

13 years ago

Hi,

I don't really like to write every time a "long" 'function()', only for passing a little callback like 'function ($v) { var_dump($v); }'...:

Nice proposal, but writing the last argument outside of the function call could be confusing... An user-function is not a language construct (like while etc.)

regards,
Bob

Am 19.2.2013 um 13:57 schrieb Marcello Duarte <mduarte@inviqa.com>:

Florin Razvan Patan

13 years ago

Hello,

On Tue, Feb 19, 2013 at 2:57 PM, Marcello Duarte <mduarte@inviqa.com> wrote:

> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
> --
> Marcello Duarte
>

I really don't like syntax for this. It makes it hard to follow. Removing
a couple of characters while making the syntax harder to follow isn't
a good thing imho.

Also it's a BC break, like Patrick mentioned.


Have a nice day,
Florin
----
Florin Patan
https://github.com/dlsniper

Levi Morrison

13 years ago

There's already been an overwhelming negative reaction to this
particular proposed syntax so I won't belabor the point much.  In
short, this is too similar to block statements and does have BC
issues.

--

IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:

function ($n) use ($m) { return $m * $n; }

Versus one potential option:

($value) |$m| => $m * $n;

This syntax is short and expressive at the expense of clarity.
Basically all short-syntax has that trade-off, so I am personally fine
with it. The only other potential problem I see is parsing it; someone
more familiar with PHP's parser would have to verify whether that
would be a problem.

Levi Morrison

13 years ago

> IF (and I stress if) we add a a shorter anonymous function syntax I'd
> like it to be geared towards one-liners because that's where the
> current syntax feels really verbose, especially when you close over
> other variables:
>
>     function ($n) use ($m) { return $m * $n; }
>
> Versus one potential option:
>
>     ($value) |$m| => $m * $n;

My apologies, this was meant to read:

($n) |$m| => $m * $n;

Morfi

13 years ago

($n) => { echo $n; }
($n) use ($m) => { echo $n; }

On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison <morrison.levi@gmail.com>wrote:

> > IF (and I stress if) we add a a shorter anonymous function syntax I'd
> > like it to be geared towards one-liners because that's where the
> > current syntax feels really verbose, especially when you close over
> > other variables:
> >
> >     function ($n) use ($m) { return $m * $n; }
> >
> > Versus one potential option:
> >
> >     ($value) |$m| => $m * $n;
>
> My apologies, this was meant to read:
>
>     ($n) |$m| => $m * $n;
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Best regards, Andrey

Marcello Duarte

13 years ago

On 19 Feb 2013, at 16:29, Morfi wrote:

> ($n) => { echo $n; }
> ($n) use ($m) => { echo $n; }

Morfi, the problem pointed out already is when you have no arguments it would be the same as the statement block, which would cause BC issues.

> On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison <morrison.levi@gmail.com>wrote:
>
>>> IF (and I stress if) we add a a shorter anonymous function syntax I'd
>>> like it to be geared towards one-liners because that's where the
>>> current syntax feels really verbose, especially when you close over
>>> other variables:
>>>
>>>    function ($n) use ($m) { return $m * $n; }
>>>
>>> Versus one potential option:
>>>
>>>    ($value) |$m| => $m * $n;
>>
>> My apologies, this was meant to read:
>>
>>    ($n) |$m| => $m * $n;
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Best regards, Andrey

--
Marcello Duarte
marcello.duarte@gmail.com
http://marcelloduarte.net

Nikita

13 years ago

On Tue, 19 Feb 2013 16:31:39 -0000, Marcello Duarte <mduarte@inviqa.com>
wrote:

> On 19 Feb 2013, at 16:29, Morfi wrote:
>
>> ($n) => { echo $n; }
>> ($n) use ($m) => { echo $n; }
>
> Morfi, the problem pointed out already is when you have no arguments it
> would be the same as the statement block, which would cause BC issues.

Why not () => { echo $n; } then?

Florin Razvan Patan

13 years ago

Hello,

On Tue, Feb 19, 2013 at 6:09 PM, Levi Morrison <morrison.levi@gmail.com> wrote:

> There's already been an overwhelming negative reaction to this
> particular proposed syntax so I won't belabor the point much.  In
> short, this is too similar to block statements and does have BC
> issues.
>
> --
>
> IF (and I stress if) we add a a shorter anonymous function syntax I'd
> like it to be geared towards one-liners because that's where the
> current syntax feels really verbose, especially when you close over
> other variables:
>
>     function ($n) use ($m) { return $m * $n; }
>
> Versus one potential option:
>
>     ($value) |$m| => $m * $n;
>
> This syntax is short and expressive at the expense of clarity.
> Basically all short-syntax has that trade-off, so I am personally fine
> with it. The only other potential problem I see is parsing it; someone
> more familiar with PHP's parser would have to verify whether that
> would be a problem.
>

I think that before we establish a syntax for this we should see if there's
a real need for this feature, and after that, get a syntax to implement the
feature.

Say we agree on the syntax above

> ($n) |$m| => $m * $n;

What happens when my one liner function needs to do one more operation
like checking the value of $n before multiplication?

I'd rather see a proposal to drop the 'function' keyword from the classes
methods and only leave the visibility scope and method name, but for
anonymous functions like this one I'd rather keep the 'function' keyword in
order to have better visibility when I'm doing a code review/scan new code
in a library.

What do you think?

----
Florin Patan
https://github.com/dlsniper

Levi Morrison

13 years ago

> Say we agree on the syntax above
>> ($n) |$m| => $m * $n;
> What happens when my one liner function needs to do one more operation
> like checking the value of $n before multiplication?

As I stated before suggesting the syntax: It's only meant for a single
expression. It's purposefully NOT intended to cover multiple
expressions.  In that case the current (verbose) syntax is better for
all criteria I care about. Additionally, neither Python nor Dart
allows multiple expressions in their short-syntax functions.

Sean Coates

13 years ago

>> Say we agree on the syntax above
>>> ($n) |$m| => $m * $n;
>> What happens when my one liner function needs to do one more operation
>> like checking the value of $n before multiplication?
>
> As I stated before suggesting the syntax: It's only meant for a single
> expression. It's purposefully NOT intended to cover multiple
> expressions.  In that case the current (verbose) syntax is better for
> all criteria I care about. Additionally, neither Python nor Dart
> allows multiple expressions in their short-syntax functions.

Have you considered how this will work/look in an array?

$a = [$b => ($n) $m => $m * $n]; // wat.

S

Levi Morrison

13 years ago

> Have you considered how this will work/look in an array?
>
> $a = [$b => ($n) $m => $m * $n]; // wat.

First off, it should be:

$a = [$b => ($n) |$m| => $m * $n];

The || make a big difference in this situation.

Secondly, if you hit a situation where the syntax is confusing, use a
less confusing syntax if possible. This goes for any type of syntactic
confusion, not just short-array syntax.

Derick Rethans

13 years ago

On Tue, 19 Feb 2013, Levi Morrison wrote:

> > Have you considered how this will work/look in an array?
> >
> > $a = [$b => ($n) $m => $m * $n]; // wat.
>
> First off, it should be:
>
>     $a = [$b => ($n) |$m| => $m * $n];
>
> The || make a big difference in this situation.

It still looks like some random characters bashed together by a monkey
with a keyboard.

cheers,
Derick

Sanford Whiteman

13 years ago

> It still looks like some random characters bashed together by a monkey
> with a keyboard.

+1, I am a fiend for ternary expressions and crazy one-liners, but
this makes me want to go back and unroll everything I've ever done
into readable code. :)

-- S.

Yahav Gindi Bar

13 years ago

On Tue, Feb 19, 2013 at 6:40 PM, Levi Morrison <morrison.levi@gmail.com>wrote:

> > Say we agree on the syntax above
> >> ($n) |$m| => $m * $n;
> > What happens when my one liner function needs to do one more operation
> > like checking the value of $n before multiplication?
>
> As I stated before suggesting the syntax: It's only meant for a single
> expression. It's purposefully NOT intended to cover multiple
> expressions.  In that case the current (verbose) syntax is better for
> all criteria I care about. Additionally, neither Python nor Dart
> allows multiple expressions in their short-syntax functions.
>
> +1

A similar syntax was applied in C# lambads. For example :
m => m * n. Though C# allows to use code block in lambdas, I do think that
we should focus on one-expression only, since the current callbacks syntax
(function() { }) is great, I believe, for multiline code.

Cyberspice

13 years ago

On 19 Feb 2013, at 12:06, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args

+1

Melanie

Guilherme Blanco

13 years ago

+1
On Feb 19, 2013 10:13 AM, "Cyberspice" <thyberthpithe@gmail.com> wrote:

Pierrick Charron

13 years ago

+1

On 19 February 2013 07:06, Sara Golemon <pollita@php.net> wrote:

Florian Anderiasch

13 years ago

On 19.02.2013 13:06, Sara Golemon wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

For completeness' sake:

The VCS argument is kind of moot if you format your source code like
it's sometimes/often seen in Haskell code:

$fp = fopen( "sample.txt"
, "r+"
);

(but mostly not with function calls, more with data structures afaik)

I know, hardly anyone uses this in PHP, but it's a workaround for the
main reasoning in the RFC.

Personally, I'm +1 :)

Greetings,
Florian

Sherif Ramadan

13 years ago

On Tue, Feb 19, 2013 at 7:06 AM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

While I think it's a good idea I just have one question about the
implication of the change. Does this mean that null will be passed to the
function argument when a trailing comma remains?

Sara Golemon

13 years ago

On Tue, Feb 19, 2013 at 6:51 PM, Sherif Ramadan <theanomaly.is@gmail.com> wrote:

> While I think it's a good idea I just have one question about the
> implication of the change. Does this mean that null will be passed to the
> function argument when a trailing comma remains?
>

No.  The trailing comma is simply ignored, there's another RFC up
about default args, but this doesn't intersect with that.

Laruence

13 years ago

On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args

-1 on this.

I really don't like this,  it look very weird, and the gain is minor.

thanks

>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Laruence  Xinchen Hui
http://www.laruence.com/

Lars Strojny

13 years ago

Hi,

Am 20.02.2013 um 06:24 schrieb Laruence <laruence@php.net>:

> On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon <pollita@php.net> wrote:
>> Opening RFC to allow trailing comma in function call argument lists
>>
>> https://wiki.php.net/rfc/trailing-comma-function-args

-1 on this as well. If you don’t like the diffs, fix the diff implementation to ignore trailing comma changes. But I guess I'm in a minority here and it is easy to prevent stuff like that with a code sniffer rule.

cu,
Lars

Florin Razvan Patan

13 years ago

Hello,

On Tue, Feb 19, 2013 at 2:06 PM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

As a person who deals with code reviews from many programmers
each day, I'd have to say this would be confusing. I do agree that
it helps consistency but by far it implies many things that are really
not what they seem.

For example, I would expect that if I have:

function A($b, $c = 'd') {}

when I see A($b, ) to have no syntax errors but rather $c defaulted to
the value in the function signature, which is not implied nor assumed
by the RFC but it would be by the one reading a function.

Then when I have

function A($b, $c = 'd', $e) {}

to be able to have A($b, , $e) which again this RFC doesn't specify
that it allows but leads to confusion.

As for the argument about the VCS, I really don't see an issue with
the current way of thing. Some people don't use the comma at the
end of the arrays and it doesn't mean that they all should.

So from my point of view, this adds more ambiguity to the language
and the problem it solves is very small.


Best regards,
Florin
----
Florin Patan
https://github.com/dlsniper

Sara Golemon

13 years ago

On Wed, Feb 20, 2013 at 12:47 AM, Florin Razvan Patan
<florinpatan@gmail.com> wrote:

> For example, I would expect that if I have:
>
> function A($b, $c = 'd') {}
>
> when I see A($b, ) to have no syntax errors but rather $c defaulted to
> the value in the function signature, which is not implied nor assumed
> by the RFC but it would be by the one reading a function.
>

Your assumption would be correct.  Since the trailing comma is
ignored, the function call happens with only one argument and the
second is left as the default.

> Then when I have
>
> function A($b, $c = 'd', $e) {}
>
> to be able to have A($b, , $e) which again this RFC doesn't specify
> that it allows but leads to confusion.
>

That function signature is invalid, so you'd never have code like that
running anyway.
The call is also invalid and again you wouldn't have code like that
because it would never run.

Thee RFC doesn't explicitly specify either of these points, but they
are implied by the patch provided which only allows for a tailing
comma at the end, not "bonus commas" in the middle or at the
beginning.

> As for the argument about the VCS, I really don't see an issue with
> the current way of thing. Some people don't use the comma at the
> end of the arrays and it doesn't mean that they all should.
>

Of course not, but as you stated it would help consistency if they could.

-Sara

Sara Golemon

13 years ago

On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

For the record, I've updated the RFC just now to include
function/method/closure declarations as well:

function foo(
$bar,
$baz,
) {

}

Not a pattern I see as much, but for the sake of consistency, it
doesn't hurt to put it on the table for discussion.

Alain Williams

13 years ago

On Wed, Feb 20, 2013 at 03:26:26AM -0800, Sara Golemon wrote:

> On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon <pollita@php.net> wrote:
> > Opening RFC to allow trailing comma in function call argument lists
> >
> > https://wiki.php.net/rfc/trailing-comma-function-args
> >
> For the record, I've updated the RFC just now to include
> function/method/closure declarations as well:
>
> function foo(
>   $bar,
>   $baz,
> ) {
>
> }
>
> Not a pattern I see as much, but for the sake of consistency, it
> doesn't hurt to put it on the table for discussion.

I would argue against the RFC.

The trailing comma is useful with arrays since it is not uncommon that members
need to be added to an array over time. This is often as a result of changes
outside of the program (eg: another user added to an ACL). Such a change does
not alter the purpose or functionality that is represented by the array, it just
does it for more somethings (users in my example).

Much source/version control is line based and so trailing commas helps keep
differences short.

With functions: I do not see arguments being added in the same way, ie you are
getting the function to do more of the same by adding an extra argument. If an
extra argument is added it is because what the function does has changed in some way.
This is very different from the just-a-bit-more scenario that you have with arrays.

If a function has a list of arguments that is expected to change, many
programmers would do that by passing an array to the function and arrays can
already have trailing commands ....

Also: many other languages (eg C, Perl) allow a trailing comma in arrays, but
not to function arguments. This change would make PHP different from what many
programmers might expect.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>

David Muir

13 years ago

On 20/02/2013, at 10:47 PM, Alain Williams <addw@phcomp.co.uk> wrote:

> On Wed, Feb 20, 2013 at 03:26:26AM -0800, Sara Golemon wrote:
>> On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon <pollita@php.net> wrote:
>>> Opening RFC to allow trailing comma in function call argument lists
>>>
>>> https://wiki.php.net/rfc/trailing-comma-function-args
>> For the record, I've updated the RFC just now to include
>> function/method/closure declarations as well:
>>
>> function foo(
>>  $bar,
>>  $baz,
>> ) {
>>
>> }
>>
>> Not a pattern I see as much, but for the sake of consistency, it
>> doesn't hurt to put it on the table for discussion.
>
> I would argue against the RFC.
>
> The trailing comma is useful with arrays since it is not uncommon that members
> need to be added to an array over time. This is often as a result of changes
> outside of the program (eg: another user added to an ACL). Such a change does
> not alter the purpose or functionality that is represented by the array, it just
> does it for more somethings (users in my example).
>
> Much source/version control is line based and so trailing commas helps keep
> differences short.
>
> With functions: I do not see arguments being added in the same way, ie you are
> getting the function to do more of the same by adding an extra argument. If an
> extra argument is added it is because what the function does has changed in some way.
> This is very different from the just-a-bit-more scenario that you have with arrays.
>
> If a function has a list of arguments that is expected to change, many
> programmers would do that by passing an array to the function and arrays can
> already have trailing commands ....
>
> Also: many other languages (eg C, Perl) allow a trailing comma in arrays, but
> not to function arguments. This change would make PHP different from what many
> programmers might expect.
>
> --
> Alain Williams
> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
> +44 (0) 787 668 0256  http://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
> #include <std_disclaimer.h>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

The one place I would find this to be super handy would be when specifying arguments to sprintf(), and other variable argument functions.

Cheers,
David

Martin Keckeis

13 years ago

2013/2/19 Sara Golemon <pollita@php.net>

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-1

For array it's okay, but for functions? I think the code is harder to read
that way...

If I would see a call written this way:
phpinfo(,)

There are three possible values: Defaultvalue, null or something differnt?

@Sara cool base idea ;-)  (https://github.com/sgolemon/objectifier)

Sara Golemon

13 years ago

On Wed, Feb 20, 2013 at 3:32 AM, Martin Keckeis
<martin.keckeis1@gmail.com> wrote:

> -1
>
> For array it's okay, but for functions? I think the code is harder to read
> that way...
>
> If I would see a call written this way:
> phpinfo(,)
>
> There are three possible values: Defaultvalue, null or something differnt?
>

You wouldn't see that call, it would be a syntax error.  You might see
something like this however, which may illustrate the same point you
were trying to make:

phpinfo(INFO_ALL,);

To me the meaning seems obvious, it's the same semantics as: $a =
array('foo',); which nobody seems to have trouble with.  I do
appreciate that you disagree, however.

> @Sara cool base idea ;-)  (https://github.com/sgolemon/objectifier)
>

Turns out niki did it first, and his approach was a lot better,
actually: https://github.com/nikic/scalar_objects

Nikita Popov

13 years ago

On Tue, Feb 19, 2013 at 1:06 PM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

Imho this change isn't necessary (though I'm also not strongly against). I
don't really buy the VCS argument, as the usage of function argument lists
and arrays are quite different. Functions have a fixed parameter
specification, so you don't really "just add another argument" (exception:
variadics). Arrays are quite different in that regard.

Also in my personal experience people quite rarely use the
one-argument-per-line notation for functions. If the line gets to long
people split the arguments to an extra line, but usually it's not necessary
to wrap things across so many lines that these concerns become relevant. (I
mean, this is PHP and not the Win32API with 12-required-arguments
functions...)

I could see a minor benefit for code generation, though there too the
difference isn't really large (especially if you can use implode).

Nikita

Sara Golemon

13 years ago

On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon <pollita@php.net> wrote:

> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>

Some unofficial votes going either way...  Let's open the voting to
see where things fall.

https://wiki.php.net/rfc/trailing-comma-function-args

Peter Cowburn

13 years ago

On 14 March 2013 08:35, Sara Golemon <pollita@php.net> wrote:

> Some unofficial votes going either way...  Let's open the voting to
> see where things fall.
>

Don't forget to start a new thread, as described in the Voting RFC [1].

[1] https://wiki.php.net/rfc/voting#voting

Kris Craig

13 years ago

On Thu, Mar 14, 2013 at 6:32 AM, Peter Cowburn <petercowburn@gmail.com>wrote:

> On 14 March 2013 08:35, Sara Golemon <pollita@php.net> wrote:
> > Some unofficial votes going either way...  Let's open the voting to
> > see where things fall.
> >
>
> Don't forget to start a new thread, as described in the Voting RFC [1].
>
> [1] https://wiki.php.net/rfc/voting#voting
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I noticed that multiple people who expressed support for the RFC on this
thread have since cast "No" votes on the RFC.  I'm confused.  Does "No"
correspond to supporting the idea in this case, or did something happen
outside this thread that changed people's minds about it?

--Kris

Lester Caine

13 years ago

Kris Craig wrote:

> I noticed that multiple people who expressed support for the RFC on this
> thread have since cast "No" votes on the RFC.  I'm confused.  Does "No"
> correspond to supporting the idea in this case, or did something happen
> outside this thread that changed people's minds about it?

Hopefully people have looked at the discussion and then changed their minds?
This would be another syntax change that will break third party tools without
any real advantage. SO while the patch may be complete for PHP, the knock on
effect still needs consideration ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Sara Golemon

13 years ago

> I noticed that multiple people who expressed support for the RFC on this
> thread have since cast "No" votes on the RFC.  I'm confused.  Does "No"
> correspond to supporting the idea in this case, or did something happen
> outside this thread that changed people's minds about it?
>

They probably just changed their minds, as happens.  The initial swell
of support was followed by a number of reasonable arguments against.
That's what the RFC process is meant to do. :)