[RFC] Allow trailing comma in function call argument lists

11 years ago by Derick Rethans — view source

unread

Opening RFC to allow trailing comma in function call argument lists

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

+1

cheers,
Derick

11 years ago by Pierre Joye — view source

unread

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

11 years ago by Patrick ALLAERT — view source

unread

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

--

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

11 years ago by Kingsquare.nl - Robin Speekenbrink — view source

unread

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

Opening RFC to allow trailing comma in function call argument lists

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

11 years ago by Marcello Duarte — view source

unread

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

11 years ago by Derick Rethans — view source

unread

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

11 years ago by Marcello Duarte — view source

unread

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.

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.

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

--

--
Marcello Duarte

11 years ago by Lars Strojny — view source

unread

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.

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

11 years ago by Leigh — view source

unread

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.

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.

11 years ago by Arvids Godjuks — view source

unread

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.

11 years ago by Marcello Duarte — view source

unread

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

11 years ago by Leigh — view source

unread

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.

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.

11 years ago by Marcello Duarte — view source

unread

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.

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.

11 years ago by Levi Morrison — view source

unread

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

11 years ago by Marco Pivetta — view source

unread

@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/

11 years ago by Christopher Jones — view source

unread

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

11 years ago by Anthony Ferrara — view source

unread

Marcello,

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

11 years ago by Paul Dragoonis — view source

unread

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.comwrote:

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

11 years ago by Michael Wallner — view source

unread

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

11 years ago by Patrick ALLAERT — view source

unread

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.

11 years ago by Bob Weinand — view source

unread

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:

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

11 years ago by Florin Razvan Patan — view source

unread

Hello,

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

11 years ago by Levi Morrison — view source

unread

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.

11 years ago by Levi Morrison — view source

unread

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;

11 years ago by Morfi — view source

unread

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

On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison morrison.levi@gmail.comwrote:

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;
--

--
Best regards, Andrey

11 years ago by Marcello Duarte — view source

unread

($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.comwrote:

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;

--

--
Best regards, Andrey

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

11 years ago by Nikita Nefedov — view source

unread

On Tue, 19 Feb 2013 16:31:39 -0000, Marcello Duarte mduarte@inviqa.com
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?

11 years ago by Florin Razvan Patan — view source

unread

Hello,

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

11 years ago by Levi Morrison — view source

unread

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.

11 years ago by Sean Coates — view source

unread

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

11 years ago by Levi Morrison — view source

unread

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.

11 years ago by Derick Rethans — view source

unread

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

11 years ago by Sanford Whiteman — view source

unread

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.

11 years ago by Lazare Inepologlou — view source

unread

2013/2/20 Sanford Whiteman swhitemanlistens-software@cypressintegrated.com

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.

Long code is not always equivalent to readable code. A shorter syntax could
improve readability in some cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );

Lazare INEPOLOGLOU
Ingénieur Logiciel

11 years ago by David Muir — view source

unread

2013/2/20 Sanford Whiteman swhitemanlistens-software@cypressintegrated.com

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.

Long code is not always equivalent to readable code. A shorter syntax could
improve readability in some cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );

Lazare INEPOLOGLOU
Ingénieur Logiciel

I think your example proves the opposite. The fist example was much easier to read and understand than the second.

Cheers,
David

11 years ago by Levi Morrison — view source

unread

2013/2/20 Sanford Whiteman swhitemanlistens-software@cypressintegrated.com

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. :)

Long code is not always equivalent to readable code. A shorter syntax could
improve readability in some cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );

I think your example proves the opposite. The fist example was much easier to read and understand than the second.

Obviously that's up to interpretation; I think the second is better
though I don't understand why ==> is there instead of something
simpler.

11 years ago by Lazare Inepologlou — view source

unread

2013/2/21 Levi Morrison morrison.levi@gmail.com

On 21/02/2013, at 6:12 AM, Lazare Inepologlou linepogl@gmail.com
wrote:

2013/2/20 Sanford Whiteman <
swhitemanlistens-software@cypressintegrated.com>

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. :)

Long code is not always equivalent to readable code. A shorter syntax
could
improve readability in some cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );

I think your example proves the opposite. The fist example was much
easier to read and understand than the second.

Obviously that's up to interpretation; I think the second is better
though I don't understand why ==> is there instead of something
simpler.

It's just an example, and it's not important. I wanted to use something
that is similar to the key-value mapping operator, but not the same.

What is important is that the short version is declarative: emphasis is put
to what to do, not how to do it. The mechanics are not exposed, and this is
why some may find it harder to understand at first sight.

Lazare INEPOLOGLOU
Ingénieur Logiciel

11 years ago by Clint Priest — view source

unread

Long code is not always equivalent to readable code. A shorter syntax could
improve readability in some cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );

I think your example proves the opposite. The fist example was much easier to read and understand than the second.
That all depends on how many languages you're versed in, the short
syntax above is common in many modern languages and has no clarity
issues for me.

--
-Clint

11 years ago by Mark — view source

unread

Long code is not always equivalent to readable code. A shorter syntax
could
improve readability in some cases.

Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );

Short:
$users->OrderBy( $x ==> $x->Surname );

I think your example proves the opposite. The fist example was much easier
to read and understand than the second.

That all depends on how many languages you're versed in, the short syntax
above is common in many modern languages and has no clarity issues for me.

--
-Clint

--

Just letting my voice hear as a "php developer" watching this list
from time to time.
As a php developer i'm heavily against adding this "feature" to php.
It makes the code very vague to understand and specially if it's
spread over multiple files.

For example file_a.php has:
$sayHi = { echo "hi"; };

Now lets say file_b.php has this:
$sayHi();

This is just code obfuscation! Please don't add it. It would be neat
as a code obfuscation technique :)

Just my 5 cents.

Cheers,
Mark

11 years ago by Yahav Gindi Bar — view source

unread

On Tue, Feb 19, 2013 at 6:40 PM, Levi Morrison morrison.levi@gmail.comwrote:

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.

11 years ago by Sara Golemon — view source

unread

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

11 years ago by Kingsquare.nl - Robin Speekenbrink — view source

unread

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

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

11 years ago by Will Fitch — view source

unread

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).

-Sara

11 years ago by Cyberspice — view source

unread

Opening RFC to allow trailing comma in function call argument lists

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

+1

Melanie

11 years ago by guilhermeblanco@gmail.com — view source

unread

+1

Opening RFC to allow trailing comma in function call argument lists

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

+1

Melanie

11 years ago by Pierrick Charron — view source

unread

+1

Opening RFC to allow trailing comma in function call argument lists

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

11 years ago by Florian Anderiasch — view source

unread

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

11 years ago by Sherif Ramadan — view source

unread

Opening RFC to allow trailing comma in function call argument lists

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

--

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?

11 years ago by Sara Golemon — view source

unread

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.

11 years ago by Laruence — view source

unread

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

--

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

11 years ago by Lars Strojny — view source

unread

Hi,

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

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

11 years ago by Florin Razvan Patan — view source

unread

Hello,

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

11 years ago by Sara Golemon — view source

unread

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

11 years ago by Sara Golemon — view source

unread

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.

11 years ago by Alain Williams — view source

unread

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

11 years ago by David Muir — view source

unread

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>

--

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

11 years ago by Martin Keckeis — view source

unread

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

--

-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)

11 years ago by Sara Golemon — view source

unread

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

11 years ago by Nikita Popov — view source

unread

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

11 years ago by Sara Golemon — view source

unread

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

11 years ago by Peter Cowburn — view source

unread

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

11 years ago by Kris Craig — view source

unread

On Thu, Mar 14, 2013 at 6:32 AM, Peter Cowburn petercowburn@gmail.comwrote:

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

--

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

11 years ago by Lester Caine — view source

unread

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

11 years ago by Sara Golemon — view source

unread

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. :)

[RFC] Allow trailing comma in function call argument lists

Please feedback,

Please feedback,

Please feedback,

Please feedback,

Please feedback,

Please feedback,

Have a nice day, Florin

Best regards, Florin

-- Lester Caine - G8HFL

Have a nice day,
Florin

Best regards,
Florin

--
Lester Caine - G8HFL