Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63872
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50A39C58.6030501@zerocue.com>
References: <508A67E6.2000405@zerocue.com>
	<50A39C58.6030501@zerocue.com>
Date: Wed, 14 Nov 2012 16:35:31 +0100
Message-ID: <CAF+90c_jVmHk_ZXc1GXNwwiZ3Zy8oubmW8gudbmi7qppH68p2A@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04083aa5eba51504ce7648e7
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor
 Method Visibility / Callability
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d04083aa5eba51504ce7648e7
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest <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 :)

--f46d04083aa5eba51504ce7648e7--