Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18422
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 25 Aug 2005 15:00:11 +0200 (CEST)
To: Stanislav Malyshev <stas@zend.com>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <Pine.LNX.4.62.0508251535230.7197@shire.zend.office>
Message-ID: <Pine.LNX.4.62.0508251452460.10004@localhost>
References: <Pine.LNX.4.62.0508021457590.2808@localhost>
	<Pine.LNX.4.62.0508251400150.10004@localhost> <Pine.LNX.4.62.0508251535230.7197@shire.zend.office>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Property Overloading RFC
From: derick@php.net (Derick Rethans)

On Thu, 25 Aug 2005, Stanislav Malyshev wrote:

> 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?

Uh? It's just a default value, which I now remember we can't do. So 
forget the " = 1" ;-)

> 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 ;)

Problem 1 is the least of the 3 problems, but introducing the keyword 
also helps solving the other two.

> 2. I don't like having to go to reflection for finding out if it's defined 
> or not.

Me neither, that's why I wrote it was a bad solution in the proposal ;-)

> 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.

If I'm not wrong, __isset() checks if something is *set* not if it's 
available. The reason for __have_prop() is to check whether something is 
declaread as "property" in the class. There is no other way of doing 
that unless we'd like to break BC.

> 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? 

If it returns false, the engine can throw an error on the line where it 
was used, not inside the __get() method itself, as that doesn't help 
debugging your code (as you don't usually know where it was called 
from).

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org