Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69327 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44846 invoked from network); 24 Sep 2013 21:36:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Sep 2013 21:36:28 -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:1433] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1A/00-44461-BD502425 for ; Tue, 24 Sep 2013 17:36:28 -0400 To: internals@lists.php.net,Robert Stoll Message-ID: <524205D8.8000608@php.net> Date: Tue, 24 Sep 2013 22:36:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: <5241F11C.5080707@php.net> <008301ceb967$b49ab190$1dd014b0$@tutteli.ch> In-Reply-To: <008301ceb967$b49ab190$1dd014b0$@tutteli.ch> 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 09:50 PM, Robert Stoll wrote: > >> -----Original Message----- >> From: Joe Watkins [mailto:krakjoe@php.net] >> Sent: Tuesday, September 24, 2013 10:08 PM >> To: internals@lists.php.net; Kristopher >> Subject: Re: [PHP-DEV] RFC: Anonymous Classes >> >> 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 ... > > [Robert Stoll] > Every syntactic sugar means more overhead for maintaining PHP and therefore > I think it is a good idea to review the idea and ask for real use cases. > However, real use cases were presented in this case which makes sense IMO > and thus I think the RFC should be accepted. > I am not a fan of anonymous classes with lot of logic in it, but small > anonymous classes can be very useful as presented before. > > One additional use case I can think of is a composition where it is not > exposed to the outside of the class. An anonymous class extending a small > interface or extending an abstract class with only a few methods seems to be > the suitable candidate here IMO. If PHP would support inner classes I would > probably prefer a private inner class when the anonymous class starts to > hold to much logic. > > Cheers, > Robert > >> 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 >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > visit: >> http://www.php.net/unsub.php > > I think sugar can have overhead ... but did you see the patch ?? In this case, there's not really any use cases you can give that absolutely require anonymous classes, it's personal preference. I'm glad that others found examples of use cases they can give, as that seems required ... I just don't really see the sense in saying that's why we should have it, because absolutely anything suggested can be achieved without it ... It's too simplistic, and wrong, to say that all RFC's require the exact same treatment; they clearly do not. If the idea is simple then the patch, and ideally the process that gets it merged should also be simple. Thanks for all the input, everyone, hope this isn't misunderstood ... Inner classes can be done, I mentioned this in the RFC, there's a patch to play with, I've not really given it a bunch of thought, so no draft yet even, I'm just saying, it's a possibility ... Cheers