Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63645
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
Sender: Maciek Sokolewicz <tularis@gmail.com>
Message-ID: <508A7835.2040802@php.net>
Date: Fri, 26 Oct 2012 13:47:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>
CC: 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 MethodVisibility
 / Callability
From: maciek.sokolewicz@gmail.com (Maciek Sokolewicz)

On 26-10-2012 12:37, Clint Priest wrote:
> ------------------------------------------------------------------------
> 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?
>

I personally don't think there's such a huge difference between the two 
'groups'. When people in group 1 use reflection to examine their 
accessors, they should have enough knowledge to understand how accessors 
are implemented. If we document it well, I don't really see that as a 
problem.

- Tul