Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <50A464C9.8070008@zerocue.com>
Date: Wed, 14 Nov 2012 21:43:05 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>, 
 Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <508A67E6.2000405@zerocue.com> <50A39C58.6030501@zerocue.com> <CAF+90c_jVmHk_ZXc1GXNwwiZ3Zy8oubmW8gudbmi7qppH68p2A@mail.gmail.com>
In-Reply-To: <CAF+90c_jVmHk_ZXc1GXNwwiZ3Zy8oubmW8gudbmi7qppH68p2A@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020508000900070809000003"
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: cpriest@zerocue.com (Clint Priest)

--------------020508000900070809000003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yeah, pretty much.  I would not say they are "hidden" from the user, 
they are simply not revealed purposely.  (see example below for reason)  
It's an irrelevant engine implementation detail.  They would simply be 
callable only because they are actually methods. They are not magic 
methods because their simple existence does not make them accessors.

Fatal error: Call to private method a::__setb() from context ''...

Or...

Fatal error: Cannot set private property a::$b.

A user seeing the first error after having defined a property would be 
like WTF?  What is __setb() and why does the engine think I'm trying to 
call it?

As the code is currently written, nearly all errors that would have 
produced confusing errors such as the former, they produce errors such 
as the latter, one that makes sense given that they are trying to set a 
property.

Nikita, you and Stas are the two most diametrically opposed on this 
issue, would you please hash it out and let me know?  You all know my 
position on what I think it should do and I'd just like this to get 
resolved.

-Clint

On 11/14/2012 9:35 AM, Nikita Popov wrote:
> On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest <cpriest@zerocue.com 
> <mailto:cpriest@zerocue.com>> wrote:
>
>     Been AWOL for a while and getting back to this, doesn't seem like
>     any resolution has occurred, just the conversation has died down.
>
> I got the feeling that in the last few mails we actually made some 
> progress and some people agreed with me that __magic accessor methods 
> and a dedicated syntax for them are not combinable semantically. Maybe 
> I got that wrong :/
>
>     I would propose that:
>
>     1) Internal accessor methods that are defined are callable directly.
>     2) Said methods are not reflected or revealed by the engine (stack
>     traces, reflection, etc would hide the engines implementation details)
>
>     I think that with the above, #1 makes it easy as no further
>     changes are required to make that happen, they're already directly
>     callable
>
>
> The current implementation just uses the __ methods internally, but 
> they are not actually magic accessor methods. That's not what Stas 
> wants (as far as I understood). So you would still have to change the 
> implementation to make them true magic methods which can be used 
> independently from the special accessor syntax.
>
>     and #2 jives with what *most userland programmers* would expect.
>
>
> So with your current plan we would end up with this:
>
> a) A dedicated accessors syntax
> b) which internally stores the accessors as methods with special names
> c) but those methods are not magic methods, so you can't get the same 
> behavior by defining them directly
> d) and the methods are hidden from the user
> e) but he can still call them (even though they don't exist if he asks 
> for them in reflection).
>
> All this sounds very odd to me.
>
> Nikita :)

-- 
-Clint

--------------020508000900070809000003--