Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63870
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: <50A39C58.6030501@zerocue.com>
Date: Wed, 14 Nov 2012 07:27:52 -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: PHP Developers Mailing List <internals@lists.php.net>
References: <508A67E6.2000405@zerocue.com>
In-Reply-To: <508A67E6.2000405@zerocue.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: cpriest@zerocue.com (Clint Priest)

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 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 and #2 
jives with what *most userland programmers* would expect.

Anyone disagree?

On 10/26/2012 5:37 AM, Clint Priest wrote:
> I'm opening up several new threads to get discussion going on the 
> remaining "being debated" categories referenced in this 1.1 -> 1.2 
> change spec:
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 
>
>
> ------------------------------------------------------------------------
> Some people are in favor of the internal functions being generated by 
> an accessor declaration should be invisible and non-callable directly. 
> Others are in favor of leaving them visible and callable.
>
> *Type 1 ( Userland Programmer )**
> *
> As a userland programmer, someone who cares nothing for "how" php 
> works, only how their own code works. If they define an accessor they 
> expect to see an accessor, reflection should reflect that there are 
> accessors and no other "methods" they did not explicitly define. If 
> they were to reflect on all of the methods of their class and see a 
> number of __getHours() they may be confused as to why or where this 
> function came from. From their perspective, they have defined an 
> accessor and "how" that accessor works on the inside is of no 
> importance to them and only seeks to complicate or confuse matters 
> when they are exposed to these "implementation details" of the php 
> language its-self. If you tried to set a value such as $obj?abc = 1 
> through an accessor which could not be set, you would probably want to 
> see an error like: Warning, cannot set Class?abc, no setter defined.
>
> *Type 2 ( Internals Programmer )**
> *
> As an internals programmer, you want nothing hidden from you. If an 
> accessor implements special __getHours() methods to work its magic, 
> then you want to see them, you want to call them directly if you so 
> choose. In effect you want nothing hidden from you. In this case you 
> probably don't even want Reflection to reflect accessors as anything 
> different than specially formatted and called methods on the class. 
> This can be understandable because you want all information available 
> to you. You would probably not be confused if you wrote $obj?abc = 1 
> and got back an error like "Fatal Error: Class->__setAbc() function 
> does not exist.
>
> *Unfortunately 80 to 95% of all people who use PHP are of the first 
> type.**
> *
> Revealing these internal matters to them would only leave them 
> confused, possibly frustrated and likely asking about it to the 
> internals mailing list to answer (repeatedly).
> ------------------------------------------------------------------------
>
> Thoughts?
>

-- 
-Clint