Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <slrnl42thm.a07.dsp@dsp.local>
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>
Date: Tue, 24 Sep 2013 13:25:21 +0100
Message-ID: <CAPMc8uaFVTUwEEWw49AgvOJxK8i-6SFdFq-RxFpbo__TRtZiWA@mail.gmail.com>
To: David Soria Parra <dsp@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01536b7cfb969404e7203a3f
Subject: Re: [PHP-DEV] RFC: Anonymous Classes
From: terence.copestake@gmail.com (Terence Copestake)

--089e01536b7cfb969404e7203a3f
Content-Type: text/plain; charset=ISO-8859-1

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.

--089e01536b7cfb969404e7203a3f--