Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69388 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 42371 invoked from network); 27 Sep 2013 10:26:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Sep 2013 10:26:15 -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:14415] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 51/00-42235-64D55425 for ; Fri, 27 Sep 2013 06:26:15 -0400 To: internals@lists.php.net,Terence Copestake Message-ID: <52455D42.8010603@php.net> Date: Fri, 27 Sep 2013 11:26:10 +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> <524205D8.8000608@php.net> <5242ADAE.2080007@php.net> <5242E88D.90407@php.net> <5244095F.3090005@php.net> 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/27/2013 10:42 AM, Terence Copestake wrote: >> Just ... Isn't that something, we can simply keep out of _this_ RFC and >> create separate RFC(s) for it later? Like it was done with "$this in >> Closures"? > > > Do we want another 5.3/5.4 closures situation? Why not iron it all out to > begin with? > > If there's a sound, logical reason not to implement the functionality in > question, that's fine. I don't understand why we keep reiterating "keeping > it simple" as if that is in itself an excuse to, in effect, rush it through > half-baked. > > In the RFC, there are use cases citing languages like Java to support this > - a language in which anonymous classes and the methods in which they're > defined, share scope. Can we then say, let's do it because it's useful in > other languages, but let's not offer the functionality that those languages > do? Also, my proposed use case being practical in the real world hangs on > resolving the scope issue, as I struggle to look past the difficulties I'd > have trying to use this in my code when it's unable to interact with the > object instance in which it is being used. > > That's all I'll say on that now; it's becoming circular. > > If you want to update my use case in the RFC, here's an expanded example of > what I imagine. I've lifted code from the documentation for Sentry* and > below it, written an alternative anonymous class API example. > > * I have no affiliation with Sentry / other membership packages are > available. > > try > { > // Find the user using the user id > $user = Sentry::findUserById(1); > // Log the user in > Sentry::login($user, false); > } > catch (Cartalyst\Sentry\Users\LoginRequiredException $e) > { > echo 'Login field is required.'; > } > catch (Cartalyst\Sentry\Users\UserNotActivatedException $e) > { > echo 'User not activated.'; > } > catch (Cartalyst\Sentry\Users\UserNotFoundException $e) > { > echo 'User not found.'; > } > // Following is only needed if throttle is enabled > catch (Cartalyst\Sentry\Throttling\UserSuspendedException $e) > { > $time = $throttle->getSuspensionTime(); > echo "User is suspended for [$time] minutes."; > } > catch (Cartalyst\Sentry\Throttling\UserBannedException $e) > { > echo 'User is banned.'; > } > > becomes: > > $user = Sentry::findUserById( > 1, > (new class implements Cartalyst\Sentry\LoginHandlerInterface > { > public function onLoginRequired() > { > echo 'Login field is required.'; > } > public function onUserNotActivated() > { > echo 'User not activated.'; > } > public function onUserNotFound() > { > echo 'User not found.'; > } > // Following is only needed if throttle is enabled > public function onUserSuspended() > { > $time = $throttle->getSuspensionTime(); > echo "User is suspended for [$time] minutes."; > } > public function onUserBanned() > { > echo 'User is banned.'; > } > public function onSuccess() > { > // Log the user in > Sentry::login($user, false); > } > }) > ); > Because in your rush to get the ironing done, you are burning clothes, putting big holes in them, and are going to be left with no clothes without big holes in them ... What we are introducing here is anonymous classes, not nested classes: class Outer { class Inner { class Again { class Inner { } } } } This requires a way to resolve complex scope issues, these are formally nested classes, as yet unsupported, formally nested classes might also look like: class Outer { class Inner { protected class Again { private class Inner { } } } } I appreciate that the only way to do this right now is with anonymous classes, but if you are doing it with anonymous classes then you, clearly, do not care about scope. The solution to the resolution of nested class scope issues does not belong as part of the RFC introducing anonymous classes but the RFC introducing nested classes, which is as yet unwritten, but totally doable. +1000 on keeping this for another RFC, because it's part of another problem ... Cheers Joe