On 09/24/2013 09:50 PM, Robert Stoll wrote:
-----Original Message-----
From: Joe Watkins [mailto:krak...@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.copest...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
