Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63878
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: <50A4627F.5000907@zerocue.com>
Date: Wed, 14 Nov 2012 21:33:19 -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: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <508A67E6.2000405@zerocue.com> <50A39C58.6030501@zerocue.com> <50A3C5AE.7080208@sugarcrm.com>
In-Reply-To: <50A3C5AE.7080208@sugarcrm.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)

*sigh*

Which error would make more sense to you Stas...

Given this code:

class a {
     public $b {
         get() { return 5; }
         private set($x) { /* do something */ }
     }
}

$o = new a();

echo $o->b;
$o->b = 42;

There are two possibilities at this point.  The code base, without all 
the work I have done to make the errors make sense will show:

Fatal error: Call to private method a::__setb() from context ''...

Or...

Fatal error: Cannot set private property a::$b.

Which makes more sense to the most people?

On 11/14/2012 10:24 AM, Stas Malyshev wrote:
> Hi!
>
>> 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?
> Yes. I strongly disagree with adding any magic to the engine that messes
> with reflection and backtraces and removes methods existing and being
> called from it. I think no "userland" programmer would have any problem
> understanding that these methods exist and how they work, just as nobody
> has problem understanding how __get works. I think adding this magic
> complicates both engine code (which will have to be supported for years
> to come) and the language, without absolutely any benefit to anybody
> except for imaginary people being scared to death by methods that they
> themselves defined showing up in the backtrace.
>

-- 
-Clint