Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69325 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39069 invoked from network); 24 Sep 2013 20:08:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Sep 2013 20:08:00 -0000 X-Host-Fingerprint: 80.4.21.210 cpc22-asfd3-2-0-cust209.1-2.cable.virginmedia.com Received: from [80.4.21.210] ([80.4.21.210:7153] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A0/10-38378-021F1425 for ; Tue, 24 Sep 2013 16:08:00 -0400 To: internals@lists.php.net,Kristopher Message-ID: <5241F11C.5080707@php.net> Date: Tue, 24 Sep 2013 21:07:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.4.21.210 Subject: Re: [PHP-DEV] RFC: Anonymous Classes From: krakjoe@php.net (Joe Watkins) On 09/24/2013 01:30 PM, Kristopher wrote: > On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake < > terence.copestake@gmail.com> wrote: > >> Playing devil's advocate here, could this feature make the language more >> expressive? >> >> Take for example an API where you'd typically wrap a method call in >> try/catch blocks to handle the various "outcomes" e.g. a user login, you'd >> maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a >> UserPasswordIncorrect exception, etc. >> >> With the addition of this syntactic sugar, the method could instead accept >> an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect >> methods. >> >> Perhaps it would also have a performance benefit over cascading through >> catch blocks? Though someone else would have to confirm that. >> > > Why wouldn't you want this to a concrete, real class? I don't see the > benefit, in your example, of doing an anonymous class vs defining an actual > class and passing that in as the handler. > People express themselves in different ways ... It is mostly just about expressing the same thing in different ways, we can find justification for it when pushed, because we are being pushed ... I'm a bit confused by this idea that every RFC has to be accompanied by a long list of use cases, expressing ideas that cannot conceivably be expressed any other way ... that doesn't make any sense, you can do almost anything a bunch of ways ... I think enough use cases have been provided, it's an established, widely used, part of OO elsewhere: The _only_ question is should we have it, which is incidentally the reason the RFC was sparse in the first place ... Cheers