Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65972 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2308 invoked from network); 19 Feb 2013 17:33:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Feb 2013 17:33:01 -0000 Authentication-Results: pb1.pair.com smtp.mail=leight@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=leight@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.174 as permitted sender) X-PHP-List-Original-Sender: leight@gmail.com X-Host-Fingerprint: 74.125.82.174 mail-we0-f174.google.com Received: from [74.125.82.174] ([74.125.82.174:36287] helo=mail-we0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 66/30-17768-C47B3215 for ; Tue, 19 Feb 2013 12:33:01 -0500 Received: by mail-we0-f174.google.com with SMTP id r6so5856623wey.19 for ; Tue, 19 Feb 2013 09:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uLHSpuQ9AwSHhqUVXuyk2HGON7/EOZxsO09ehaolnxY=; b=aRkbkOEqYXhMmaS8q8SHi5x7/GxCcPwRioXQDJ7joYkRyk3NSowhdqrpMTLgikxVsg mACtuC9gBAbBippx0AmwipEjluEdcCwC4ns3nSGbiHXArvrOJyq9YyLBP4m478RPseuL AZqXpLnO09x4+dfUNOHZjUYrs0kU+U0uIUDc8g/ybVdJHj7kfq6BI2sftDybHC/aY8xD S+wYJeaNZE4fmATR6Z4yqopiJq6UXHIm46C8PYIa9vsT9T2EkyUEyoddgR3pj19gwBc5 QeGszfdlkBui3UmBmHAWbP8ESF13OVrobTqKzbWJhBcn4Vd7o269zHQrvEb6hoeeBiNR FZsA== MIME-Version: 1.0 X-Received: by 10.180.95.199 with SMTP id dm7mr14623498wib.20.1361295177739; Tue, 19 Feb 2013 09:32:57 -0800 (PST) Received: by 10.217.2.209 with HTTP; Tue, 19 Feb 2013 09:32:57 -0800 (PST) In-Reply-To: References: <8490FC41-2696-4948-83A1-3931674183B0@gmail.com> <3EBB0AF2-A114-4652-806B-C50DD8F9557D@inviqa.com> Date: Tue, 19 Feb 2013 17:32:57 +0000 Message-ID: To: Marcello Duarte , Levi Morrison Cc: PHP Internals Content-Type: multipart/alternative; boundary=f46d041825ce80ee5e04d6173b9a Subject: Re: [PHP-DEV] [RFC] Short syntax for anonymous functions From: leight@gmail.com (Leigh) --f46d041825ce80ee5e04d6173b9a Content-Type: text/plain; charset=ISO-8859-1 On 19 February 2013 16:46, Marcello Duarte 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 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. --f46d041825ce80ee5e04d6173b9a--