Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63491
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.143 as permitted sender)
Message-ID: <507E846A.2030805@sugarcrm.com>
Date: Wed, 17 Oct 2012 13:11:54 +0300
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>, 
 PHP Internals <internals@lists.php.net>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local> <507D24E0.9070203@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6DC9@MBX202.domain.local> <507D5199.3090203@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6F1D@MBX202.domain.local> <507D6675.3080206@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B7805@MBX202.domain.local>
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B7805@MBX202.domain.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> That makes some sense, still the issue Nikita brought up is that the
> __getHours() should not be callable.

I don't see any use case for this requirement. What *requires* that it
won't be callable and why it is so necessary that we introduce
additional complexity into the engine just to do it?

> This isn't the way isset() works, isset() will return true for a
> variable with a value of 0

Exactly my point. Your code (with != NULL) will return false while real
isset() will return true.

> AFAIK, there is no way to implement isset() in the same way, see my
> previous post about how isset() already causes a fatal error against
> the return value of a function.

Of course there is. Again, you're confusing implementing it in PHP
(which also possible but harder) and doing it in the engine (which
should be as easy as calling right functions/opcodes).

> When you say "check" do you mean "not allowed to compile?"  There is
> a runtime check that favors a property over an accessor, again Nikita
> wants to invert that and I agree.

I mean issuing E_STRICT or whatever we do in other cases of LSP violations.

> This is not true, see my previous post demonstrating that isset(a())
> causes a fatal error.

I'm not talking about applying isset to non-variable. isset(blah bah
blah) will also cause a fatal error. I'm talking about applying isset to
a proper variable (or whatever is looking as one). isset($foo->bar)
should never fail (to a reasonable degree - if you have accessor that
gets out of memory, etc. we can't do much there) however $foo->bar is
implemented underneath - it should only return true/false.

> public read-only $xyz; 	- Tells me that the property $xyz cannot be
> written to and furthermore cannot be over-ridden (the purpose of the
> read-only keyword).
> 
> To be clear, the read-only keyword specifically means that no
> sub-classes may make this property writable, in other words the
> "non-writable" aspect means it is final.

This sounds way too complex and too much magic. I'd rather have people
implement it in user-space than introduce this complex and un-obvious
convoluted concepts into the language.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227