Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sun, 7 Aug 2005 20:29:16 +0200 (CEST)
To: Ilia Alshanetsky <ilia@prohost.org>
cc: internals@lists.php.net
In-Reply-To: <42F64DC8.2000205@prohost.org>
Message-ID: <Pine.LNX.4.62.0508072011520.5514@localhost>
References: <Pine.LNX.4.62.0508021457590.2808@localhost> <42F64DC8.2000205@prohost.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Property Overloading RFC
From: dr@ez.no (Derick Rethans)

On Sun, 7 Aug 2005, Ilia Alshanetsky wrote:

> Derick Rethans wrote:
> > Problems:
> > 1. There is no way to document the 'virtual' properties with any of the
> > existing
> >    documentation tools (such as phpdoc and doxygen)
> 
> Rather then adding abstract properties, why not simply document the possible
> values inside the doc comments ala:
> /**
> * @var abstract int   Contains all X
> */

That would work, if __set and __get were also called for declared 
properties... but they don't do that so you need some keyword - or break 
BC.

> > 2. There is no way how the magic methods know if a specific 'virtual'
> > property
> >    exists or not as those properties are not declared usually - unless you
> >    define an array with property names as a class constant (which is not
> >    allowed either).
> 
> That's the whole concept behind the feature, if the values were known you may
> as well use clearly declared property and method names.

True, unless you want to force all property access to go through a 
setter/getter for all declared properties for checks. This is also 
useful for catching typoes:

<?php
    error_reporting(4095);

    class foo {
        public $foo;
    }

    $obj = new foo;
    $obj->fo = 42;
?>

does not throw any notice now for BC reasons.

> > 3. There is no way for the magic methods to return a meaningfull 
> >    error when a property doesn't "exist". Of course it is possible 
> >    to throw an error with "trigger_error" or "throw" in case a 
> >    property doesn't "exist" in a specific class, but the file and 
> >    line numbers would not match the actually get/set action. 
> >    debug_backtrace() can be used to retrieve the correct file and 
> >    line, but as you have to do this for every class where you want 
> >    to use setters and getters *and* you have to implement your own 
> >    error message rendering function this is not really a suitable 
> >    option either.
> 
> How about adding a 3rd optional argument to __get and __set which would be an
> array of acceptable values for the "name" parameter? If there is a mismatch a
> standard warning message will be raised if this parameter was supplied.

How does the engine know which list is allowed? The engine is calling 
the __set and __get methods, not users. The whole idea of using a 
keyword here is to provide the engine with such a list.

Derick