Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63438
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
Sender: amaury.bouchard@gmail.com
In-Reply-To: <CACxA8bkeZJrDZ4XoKkOx9SHsHBfAgQH_gB00Opa-q1AfH0d=fA@mail.gmail.com>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
 <CACQesk5MLCqhdKr9j30WmL6ySTeMpVVEs9q2UfOjYbA+4bp_Yw@mail.gmail.com>
 <9570D903A3BECE4092E924C2985CE485612B655A@MBX202.domain.local>
 <CAPaKmRkxYDWfYcHwv64XTpnOsQJPsm+Cbx34R1J+VecNRUFbnA@mail.gmail.com> <CACxA8bkeZJrDZ4XoKkOx9SHsHBfAgQH_gB00Opa-q1AfH0d=fA@mail.gmail.com>
Date: Tue, 16 Oct 2012 11:32:31 +0200
Message-ID: <CAPaKmRkbazZTqOeomJGs0xJnVBaMPJU1aWSck=CpDh==eM_BoQ@mail.gmail.com>
To: Jazzer Dane <tbprogrammer@gmail.com>
Cc: Clint Priest <cpriest@zerocue.com>, Etienne Kneuss <colder@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0444e8698b814504cc29d6b7
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: amaury@amaury.net (Amaury Bouchard)

--f46d0444e8698b814504cc29d6b7
Content-Type: text/plain; charset=ISO-8859-1

This discussion is opened in the dedicated thread. I used my proposal as an
example to illustrate my point of view, not to pollute this thread.

2012/10/16 Jazzer Dane <tbprogrammer@gmail.com>

> I prefer the current syntax to your proposal because:
>
> 1) It is not at all obvious which side is which. Example:
>     *protected:private
> *    Is protected* *for get? Or set? The average PHP developer will have
> no idea. In fact, they likely won't know that they even correlate to get
> and set.
>
> 2) There is no such syntax already in PHP.  (And on a more personal note,
> I don't think I've ever seen that syntax in any other language that I've
> worked in before. Which means it's even *more-so* out of people's comfort
> zones.)
>
> The current read/write syntax works, and none of the discussion I've read
> thus far would sway me towards any other option.
>
> That being said, I wouldn't contest to hearing - in more detail - your
> reasoning behind why we should use it instead of the current syntax.
>
>
> On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard <amaury@amaury.net>wrote:
>
>> 2012/10/15 Clint Priest <cpriest@zerocue.com>
>>
>> > Also, your "should be valid" statement implies that you feel properties
>> > and accessors are the same and they are not, internally.  When a class
>> > attempts to implement an interface a "function check" is done and since
>> > there is no __getXX() function defined it would fail to implementation
>> > check against an interface.
>> >
>> > I cannot stress enough that properties != accessors in any way except
>> the
>> > syntax in which they are used ($o->xyz) or ($o->xyz = 1), that is their
>> > *only* similarity.
>>
>>
>> I disagree. That's why I said this is a matter of choice. A philosophical
>> choice.
>> I don't see properties and accessors like different things which are
>> accidentally written the same. Accessors are a layer upon properties. It's
>> a magical layer, trying to mimic accessors.
>> It's a bit like aspect-oriented programming: you can add layer but the
>> core
>> is still the same (from a developper point of view, not from the PHP
>> interpreter point of view).
>>
>>
>> See another argument: My proposal for read/write accessibility definition.
>> When I suggested to allow this syntax: "public:private $abc;"
>> some people objected that it's the same than "public $abc { get; private
>> set; }"
>>
>> So, if I understand what you said, for you it's deeply different and
>> comparing them is like comparing apples and oranges. I disagree. I still
>> think my syntax is better (and could be implemented with better
>> performance), but it's normal to compare them, because they (can) offer
>> pretty much the same functionnalities.
>>
>
>

--f46d0444e8698b814504cc29d6b7--