Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64835
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50EF3C9C.3020701@sugarcrm.com>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com>
	<CAF+90c9=HgRLHv4o=5dGkQzZPC5Q0tbPC8GD9AZ13Jwkr0pOcw@mail.gmail.com>
	<4ED7146272E04A47B986ED49E771E347BB3D6ABCB3@Ikarus.ameusgmbh.intern>
	<50EC5F8F.8010703@mrclay.org>
	<CAF+90c96OZcBfDEQDEwHVEG78HTirhKONXczEhZUvxQg10MNhA@mail.gmail.com>
	<50EF3C9C.3020701@sugarcrm.com>
Date: Fri, 11 Jan 2013 00:33:20 +0100
Message-ID: <CAF+90c8=GVNs_=JZWubs=vodsdrh06q=hA9uoZ1rjwZfh=qFLg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec55404a2a995ee04d2f79a5a
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: nikita.ppv@gmail.com (Nikita Popov)

--bcaec55404a2a995ee04d2f79a5a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 10, 2013 at 11:11 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> The proposal is pretty clear, but could you explain this part:
>
> The current accessors proposal will need special handling of the
> typehint in any case (it can't be handled as a normal method typehint).
>
> What special handling is required?
>

I have written that in anticipation of a rewrite of the current automatic
accessor implementation. Currently it creates a string of PHP code and
compiles it as the method body. We were planning to replace this with
handling directly in the object handlers (because automatic accessors just
need to use the "normal" property code rather than the accessor one). In
this case we'd have to handle the typehint explicitly. But I'm not sure
whether we will still do this, so I'm not sure whether that statement in
the RFC is still true. On this subject, are you (personally) okay with the
current approach for creating automatic accessors (i.e. create PHP code
string and compile)?

> One question that still needs to be discussed is what syntax regarding
> > parentheses we want to use if this makes it. Currently both set { } and
> > set($foo) { } style accessors are supported. Do we want to keep those two
> > with the new syntax?
>
> Within this context, I'd prefer getting rid of set {} and only have
> set($param) {}. You don't save that much typing and you do it at the
> cost of additional obscurity and complexity - now every developer and
> every tool that deals with it needs to remember there's hidden $value
> parameter. IMHO not worth it. I can see what "get;" gives you - you can
> say "just do the natural thing". But if you start writing code anyway -
> i.e. if you do {} - then I think it should look like a real function.
>

Just to make sure I got it all right, you are suggesting:
 * Parentheses must be used on all accessors, so it's set($value) {} and
get() {} and isset() {} and unset() {} and something like get {} is not
possible?
 * Automatic accessors don't have parentheses so they are just set; get;
isset; unset;

Is that right? If so, then I think it's a reasonable approach.

Nikita

--bcaec55404a2a995ee04d2f79a5a--