Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 25 Aug 2005 15:48:43 +0300 (IDT)
To: Derick Rethans <derick@php.net>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <Pine.LNX.4.62.0508251400150.10004@localhost>
Message-ID: <Pine.LNX.4.62.0508251535230.7197@shire.zend.office>
References: <Pine.LNX.4.62.0508021457590.2808@localhost>
	<Pine.LNX.4.62.0508251400150.10004@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Property Overloading RFC
From: stas@zend.com (Stanislav Malyshev)

DR>>If nobody as any better idea on how to solve it I'd like to start 
DR>>implementing it.

Some questions about the RFC:

1. What exactly property public $x = 1; means? I.e., first of all, what 
"1" means - does it mean that __get guarantees to return 1 on __get("x") 
if it was never set? Should PHP somehow take care of that or is it 
responsibility of __get writer? How PHP should act on this - should it 
define entry in the hashtable or should it just ignore it? What 
protected/private means there too? Would PHP have to take care for 
inheritance and if so - how will it be enforced so that __get can't be 
called for protected property?

Altogether, problem (1) by itself has much easier solution - just add a 
keyword (or fix existing keywords) to phpdoc/doxygen allowing to document 
the thing without having language construct for it. I don't see why would 
phpdoc require PHP engine support concept of virtual property in order to 
document it. Afeter all, people routinely document code before even 
writing it ;)

2. I don't like having to go to reflection for finding out if it's defined 
or not. Also, would __have_prop be overridable and how it is different 
from __isset existing now? If it's overridable, I don't see why PHP engine 
needs anything to do with it - you always can write a method 
and name it __have_prop and call it :) If it's not - you will be asked to 
make it overridable almost instantly. So again I'm not sure what would be 
PHP support for this thing.

3. I recognise that there is a problem with __handlers diagnostics, but I 
don't see how returning true/false would help you - you wan't know what 
failure 'false' means still - what if there's another failure besides 
property not existing in __handler? 

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115