Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83680
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALrkBjYqMGKcb-Bio867tRmaiAgkmiGB-pTE7gsXtaUxcS_iJg@mail.gmail.com>
References: <CABDNdAE+7J3ViNR8844kBQsYzLDsWP-YAkKSQhD8v5GFL1Ky-A@mail.gmail.com>
	<CALrkBjYqMGKcb-Bio867tRmaiAgkmiGB-pTE7gsXtaUxcS_iJg@mail.gmail.com>
Date: Tue, 24 Feb 2015 13:16:17 -0500
Message-ID: <CABDNdAGh=i164nmLxM_1go+PqZz3_SXG8Rid8eQ-gFMdKovH_w@mail.gmail.com>
To: Mike Willbanks <pencap@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Anonymous Classes
From: pjsturgeon@gmail.com (Philip Sturgeon)

On Tue, Feb 24, 2015 at 12:21 PM, Mike Willbanks <pencap@gmail.com> wrote:
>
>
> On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon <pjsturgeon@gmail.com>
> wrote:
>>
>> Good day!
>>
>> https://wiki.php.net/rfc/anonymous_classes
>>
>> There's a little RFC + patch that Joe Watkins put together, and as
>> before with the ArrayOf RFC, I'll be helping out.
>>
>> So, lets get this discussion rolling.
>>
>> It was declined for PHP 5 some time ago, and has returned now to try for
>> PHP 7.
>>
>> The usage of anonymous classes to some will be instantly offensive,
>> but really it comes down to the use case. The usage of anonymous
>> functions compared to declared functions is pretty much the exact same
>> thing as anonymous classes.
>>
>> Other than examples on the RFC, Fractal would certainly be happy to
>> have them: http://fractal.thephpleague.com/transformers/
>
>
> I would also find myself to be a very happy consumer of this.  It can
> provide the opportunity of getting rid of a large amount of boilerplate.  In
> addition, there has been several times when implementing single use
> extensions for say view libraries (Plates extensions comes to mind) or
> Plugin handling for things like Zend Framework 2 and there has been several
> times I utilize a closure with an array to get around having an object
> simply due to you want to have a callback but with some form of definition.
> I think there is a very large use case here and something that would be a
> great addition to the language.  Sure, I could make a class and extend it
> just like this would do but for the convenience of the implementation it is
> sometimes better to do a simple closure.
>
>> Defining a class properly is certainly still going to be the majority
>> of uses of classes in PHP. That helps with the Optimizer, and helps
>> code reuse.
>>
>> Sadly due to the way in which people have had ONE CLASS ONE FILE
>> drilled into their head since PEAR and continuing through Zend and
>> PSR-0, it can become a PITA to add some simple functionality if a
>> small class is needed for one tiny thing.
>
>
> I see the point here, but the argument to me seems void.  Nothing wrong with
> a simple class one file for a small class.
>

Something doesn't have to be "wrong", another approach can just be
more convenient, or handy for different use cases.

One class one file can be rather slow depending on the autoloader
setup, and depending on whether zend optimizer is enabled or not. For
a distributed application running on mostly crap shared hosting,
relying on Zend Optimizer is not an option, so the more of these
little one-class one-file situations you have the worse it becomes.

This RFC offers a solution for people that is not "Jam a bunch of
these classes at the top of the current file" or "Make a whole load of
one-time use classes to avoid that mess, plus people will snort and
shame you for failing to follow decade old best practices."