Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54386
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A1.D0.24235.37AFA3E4@pb1.pair.com>
References: <4E3AF896.2090106@officechristmas.co.uk>
	<A1.D0.24235.37AFA3E4@pb1.pair.com>
Date: Thu, 4 Aug 2011 22:42:04 +0200
Message-ID: <CAA1M144QC2_T4sZWx_e9HO4OxtUe5oBqcJJqUtFCupyu29rzWg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001517576f647d55e304a9b40320
Subject: Re: [PHP-DEV] Re: An implementation of a short syntax for closures
From: jerem.poulain@gmail.com (=?ISO-8859-1?Q?J=E9r=E9my_Poulain?=)

--001517576f647d55e304a9b40320
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi every one,

This message is also my first one. I've been following internals for few
weeks now.

I really don't think adding more short syntax would be a good idea, at leas=
t
this one.

PHP is a very popular language for many reasons, it's C-like, easy readable=
.
We all had to read some code made by others, most of the time without any
comment. Even with big and complicated code, keywords like function and
return help understanding because you can identify some parts of code
quickly.

Most of developpers use an IDE which use syntax colors and autocompletion s=
o
that writing and analysing code is not a big deal. It wouldn't be that easy
if too many short syntax had been implemented.

All the given examples show closures with one instruction. It would be a
nightmare with more lines...

J=E9r=E9my Poulain

2011/8/4 Matthew Weier O'Phinney <weierophinney@php.net>

> On 2011-08-04, Jezz Goodwin <jezz.g@officechristmas.co.uk> wrote:
> > --------------060805070009050707030403
> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
> > Content-Transfer-Encoding: 7bit
> >
> > Hello PHP Internals,
> >
> > This is my first message to the list. I've been reading via the archive
> > since I read the 5.4RC1 announcement. (Keep up the great work guys - I'=
m
> > loving the new stuff)
> >
> > Up until now I haven't had anything to say that wasn't already being
> > talked about, but the topic of short hand syntax is of particular
> > interest to me.
> >
> > Before I start, I think I need to make clear that I am in general not a
> > fan of making cryptic code (ala perl). I tend to use long descriptive
> > variable names and try to make my code easy to read so that comments
> > aren't usually necessary.
> >
> > Saying that though, I am a big supporter of the new short hand array
> > syntax. From a grammatical point of view, I see no reason why my code
> > needs to be scattered with the word 'array'. The simple square brackets
> > ['a'=3D>'b'] I find just as easy to understand and they don't confuse m=
e.
> > (unlike something along the lines of regex, that can easily confuse).
> >
> > I see the desire to wanting to remove the word function as a similar
> > issue. When you use inline functions a lot, your code is filled with
> > lots of the word 'function'. This word doesn't necessarily need to be
> > there for your code still to make sense.
> >
> > Also, on a similar vein of thought, if your function is only doing
> > something small, why do we need to put the word 'return' in there?
>
> Well, for one, it'd be a huge disconnect between the current behavior of
> functions and the new syntax. In PHP, if you have no explicit "return"
> in your function, a null is implicitly returned. If you were to change
> this so that whatever the value of the last assignment or line was is
> returned, we'd have a huge BC break -- even if this were only in
> lambdas.
>
> I agree that shorter notation is often nice as it allows the syntax to
> get out of the way and potentially make code more readable. However,
> that's true only to a point -- if you go too far in the opposite
> direction, you end up with code that's unreadable as you have to inject
> context. I personally feel the proposed (by the original poster) lambda
> syntax falls in this category -- I found it _more_ difficult to
> understand the execution flow, and I suspect this was in large part
> because it stopped resembling traditional PHP syntax.
>
> Of the syntax changes you propose below, the only one that seems like it
> retains readability to me is the very first -- and even that one, I
> suspect, would cause some issues for the lexer.
>
> > I have been thinking of what syntax(s) could work to shorten the code
> > but not to make the code confusing. I am splitting up my ideas in to
> > separate sections. I think that if a short-hand function syntax is to b=
e
> > accepted, it should be useful in many circumstances - eg, it shouldn't
> > necessarily be limited to one liners.
> >
> >
> >
> > Okay, here is a base example:
> >
> > $modify =3D function( $x )use( $my_constant ){ return $x + $my_constant=
; };
> >
> >
> > 1) REMOVING THE WORD 'function':
> >
> > One solution is to simply remove the word function completely:
> >
> > $modify =3D ( $x )use($my_constant ){ return $x + $my_constant; };
> >
> > On first glance, to me, this doesn't look like I'm starting to write a
> > function. I could perhaps be opening a bracket to do some maths. So,
> > what could be done to make it more obvious? I suggest using a character
> > to represent function. Personally I like colon:
> >
> > $modify =3D :( $x )use( $my_constant ){ return $x + $my_constant; };
> >
> > Now, I know this doesn't immediately scream function, but it is a
> > different/specific syntax which should hopefully lead to less confusion=
.
> >
> >
> >
> > 2) REMOVING THE WORD 'return':
> >
> > Okay, my function is still a bit wordy for what it's doing. How do we
> > remove return? I quite like the use of =3D> that has been suggested in
> > previous posts.
> >
> > $modify =3D :( $x )use( $my_constant )=3D> $x + $my_constant;
> >
> >
> >
> > 3) REMOVING THE WORD 'use':
> >
> > Personally I don't think use is causing a problem, I find it helps the
> > grammar of this function. If it was to go though, it could be replaced
> > with something like a colon:
> >
> > $modify =3D :( $x : $my_constant )=3D> $x + $my_constant;
> >
> > Is this going too far? Is it now too cryptic?
> >
> >
> >
> > 4) REMOVING THE BRACKETS?
> >
> > In lots of the examples of short hand closures in other languages there
> > are no brackets. I think that might be going too far, but perhaps not:
> >
> > $modify =3D : $x : $my_constant =3D> $x + $my_constant;
> >
> > Too much! This line simply confuses me!
> >
> >
> >
> > OTHER EXAMPLES
> >
> > So, personally I don't think shortening needs to go as far as 3 or 4.
> > But, I am a fan of 1 and 2.
> >
> > To demonstrate more how this might look, I'm using the code examples
> > Lazare used in his original post:
> >
> > // Mapping:
> > $a->select( function($x){ return $x->getName(); } );
> >
> > // Filtering:
> > $a->where( function($x)use($y){ return $x=3D=3D$y; } );
> >
> > // Currying:
> > $add =3D function($x){ return function($y)use($x){ return $x+$y; }; };
> >
> >
> >
> > With my examples of shortening, these become:
> >
> > // Mapping:
> > $a->select( :($x)=3D> $x->getName() );
> >
> > // Filtering:
> > $a->where( :($x)use($y)=3D> $x=3D=3D$y );
> >
> > // Currying:
> > $add =3D :($x)=3D> :($y)use($x)=3D>$x+$y ;
> >
> >
> > Hmm... I don't like my currying example, it's starting to boggle my
> > mind. How about:
> >
> > $add =3D :($x)=3D>( :($y)use($x)=3D>$x+$y );
> >
> > Much better.
> >
> >
> >
> > Regardless of all of this, I actually don't find myself using too many
> > inline functions. (Not to the extent I was writing 'array' all over my
> > code anyway) - So I can't argue srongly about function shortening makin=
g
> > it's way in to PHP.
> >
> > Perhaps once we're all using inline functions on every other line of ou=
r
> > code there'll be a bigger demand for it!
>
>
> --
> Matthew Weier O'Phinney
> Project Lead            | matthew@zend.com
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001517576f647d55e304a9b40320--