Re: RFC: Anonymous Classes

From: Date: Fri, 27 Sep 2013 10:26:10 +0000
Subject: Re: RFC: Anonymous Classes
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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

Thread (55 messages)

« previous php.internals (#69388) next »