On Fri, Sep 27, 2013 at 11:26 AM, Joe Watkins <krak...@php.net> wrote:
> 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
>
I think you've become confused with my intentions here. My example is not
of the internal workings of an API and I'm certainly not talking about
nested classes. My example is of a third party using an API from the
outside. Currently, the way the package given in my example communicates is
by using exceptions to signal what happened. What I'm demonstrating is that
a more expressive way to do this would be to instead pass a callback
anonymous class to handle those outcomes, rather than having a series of
catch blocks.
I only think it would be good to actually discuss (i.e. _discuss_ i.e. not
dismiss based on personal preference or deflect using obscure metaphors)
the scope implications of this feature which inherently poses questions
about scope. I don't understand the insistence on addressing this in a
separate RFC when it is pertinent to this very feature.
