Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69326
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Joe Watkins'" <krakjoe@php.net>,
	<internals@lists.php.net>,
	"'Kristopher'" <kristopherwilson@gmail.com>
References: <D9.10.12097.032EF325@pb1.pair.com> <alpine.DEB.2.10.1309230946590.5168@whisky.home.derickrethans.nl> <CAMyk_AaEZRqMwFXKhHyHn4PvxhPdCqwP1Cn8vmnoajW38ZSE5A@mail.gmail.com> <slrnl42thm.a07.dsp@dsp.local> <CAPMc8uaFVTUwEEWw49AgvOJxK8i-6SFdFq-RxFpbo__TRtZiWA@mail.gmail.com> <CAF9U7z85iJsHppjpjUNZ3TT=Oq17_FHoXzE-Xv8BwczWXjK6cw@mail.gmail.com> <5241F11C.5080707@php.net>
In-Reply-To: <5241F11C.5080707@php.net>
Date: Tue, 24 Sep 2013 22:50:28 +0200
Message-ID: <008301ceb967$b49ab190$1dd014b0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQJGslghy2riouQ2rKPCaU+LhydUQwMNMGK/AnKZ5/cBe4Ti8AF310+zAqKO9mACb9fas5h5Ow8w
Content-Language: de-ch
Subject: RE: [PHP-DEV] RFC: Anonymous Classes
From: rstoll@tutteli.ch ("Robert Stoll")


> -----Original Message-----
> From: Joe Watkins [mailto:krakjoe@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.copestake@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