Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAB6YZuwfGhh=EBJySNndtRjstpbvGxvHoWKV=5GUNrx8Prc1tA@mail.gmail.com>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
 <CAESVnVq9kBhK_uEH2-HvQN4Wv8DVSnwc9ukRjrQ0KNjUbaAD7g@mail.gmail.com>
 <55E77CA9.7050609@gmail.com> <CAB6YZux4uYG7u0XRc_56MWFo+8G_h_VZZbWhCDVqA7hdu5XSpg@mail.gmail.com>
 <55E81959.6040305@gmail.com> <CAB6YZuwimHWkh8ddvkagmXRQVCK-joUSmMYKKxxjx22BbktSRg@mail.gmail.com>
 <CAEU6NAdfF0w383CNF46B8-Ly2Me+nzwpDFUvjeR4ZHk3x1MoUQ@mail.gmail.com> <CAB6YZuwfGhh=EBJySNndtRjstpbvGxvHoWKV=5GUNrx8Prc1tA@mail.gmail.com>
Date: Fri, 4 Sep 2015 10:00:18 +0200
Message-ID: <CAEU6NAfF_jDy=cQdJzGNQ2a+AMiHc4JT6fTXcra8BoQUNyN1MA@mail.gmail.com>
To: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043bdf549d3780051ee74b54
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: peter.e.lind@gmail.com (Peter Lind)

--f46d043bdf549d3780051ee74b54
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4 September 2015 at 09:43, Pavel Kou=C5=99il <pajousek@gmail.com> wrote:

> On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.lind@gmail.com> wrote=
:
> > On 4 September 2015 at 08:44, Pavel Kou=C5=99il <pajousek@gmail.com> wr=
ote:
> >
> > You're arguing that, subjectively, to you - parentheses make things
> harder
> > to read. For others they clarify things.
> > It should be obvious to everyone that this particular path of the
> discussion
> > has about as much merit as tabs vs spaces.
>
> Sure, it is subjective - but what isn't?
>
>
Consistency isn't.



> > That being the case, I would argue for consistency and simplicity. If y=
ou
> > need parentheses for other variants of this, require parentheses all th=
e
> way
> > through. It will be simpler to learn and trip fewer people up.
>
> Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
> IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
> a result of the combination of amendments #2 and #3. I honestly do not
> know if I wrote the parenthesis right now or not (probably not),
> because there's simply just too many of them.
>
> Sure, parenthesis can help people understand things, but I'd say that
> at the same time, too many of them can be a problem as well (as the
> fun name for LISP - "lost in stupid parenthesis" - suggests).
>
>
Is it? And are the examples you make use of the only two options?
What about requiring parentheses around arguments, but not around the
function body? That would guard against stupid "I'll add another argument
... why isn't it working?!?!?!" errors (getting a syntax error and then
having to fix your code isn't easier than just consistently adding
parentheses around arguments).


> > Just think, if whoever constructed the if conditional hadnt thought "he=
y,
> > let's be clever and save some keystrokes by making the curlies optional
> in
> > some cases" we wouldn't have the multitude of bugs and security holes w=
e
> > know to exist, we wouldn't have to warn the young'uns against improper
> use
> > of if, we wouldn't have to write codesniffer rules against single line
> ifs,
> > etc, etc.
> >
> > Any argument to the effect of "let's be clever" or "it'll save some
> > keystrokes" is void. Period.
>
> This is not about saving characters, it's about not overcomplicating
> things.
>

You're aiming for the "let's be clever" camp, far as I can tell.




--=20
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype>

--f46d043bdf549d3780051ee74b54--