Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63494
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B6434@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B6434@MBX202.domain.local>
Date: Wed, 17 Oct 2012 12:34:27 +0200
Message-ID: <CAF+90c_ZOwsVW-vARgDSrUF1R9y-LFkAR58dRQUmM3VyHVZQEA@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints /
 Accessor Syntax
From: nikita.ppv@gmail.com (Nikita Popov)

On Mon, Oct 15, 2012 at 2:11 PM, Clint Priest <cpriest@zerocue.com> wrote:
> So the above would actually introduce an get/set accessor rather than a
> property, correct?
Preferably it would a faster C based implementation for the check, but
in principle it could also use accessors to achieve the goal.

> If we were to abandon the long form ( set(DateTime
> $date) { ... } ) and go back to the original syntax, then the only way to
> "type hint" would be with no custom accessor logic, which I don't think
> makes sense.
Why? My point was that you could use that syntax with accessors too,
just like you can in C#:

    public DateTime $date {
        get { ... }
        set { ... }
    }

I don't know whether this is better or worse though. I like it because
it would be consistent between typehinted properties without accessors
and typehinted properties with accessors. But I can see how people
don't like the magic $value variable.

> I can agree though that the even further abbreviated syntax  -> get/set
> accessor would be nice, however many have already pointed out that these
> "equivalents" reduce clarity, especially for the less "up to speed" of th=
e
> developers.  If they were to encounter that, they may have to really do s=
ome
> digging to realize that it=92s a "super auto implemented" accessor.
They don't really need to know that they are auto implemented
accessors (where would it make a difference?) Maybe they won't even be
accessors. It's just an implementation detail. From looking at it,
it's just a property with a type, just like you know it from C++, C#,
Java or whatever.

Nikita