Re: Property Overloading RFC

Hi, As for the first question of how to document virtual properties, I have been recommending that users do this textually inside the docblock for __get()/__set(). This is actually ideal in almost every case, as anyone using __get()/__set() for finite, concrete properties should almost definitely be instead using plain old properties. I wonder if adding this language feature might be a bit too hopeful. For instance, most implementations I have seen of __get()/__set() use them because it isn't possible to know the names of the variables in advance. Simplexml and ext/soap are great examples of extensions that were they implemented in userspace would not be able to use the abstract/virtual keyword proposed because until the specific class is instantiated, one can't know what they will be working with. The Savant template engine may use them for grabbing filtered variables in the future, another good example of "you must document this with prose, not with program syntax". Having said this, if the proposal continues, I do have some suggestions. 2) <?php class Base { abstract public $x = 1; function __get($name) { if (!$this->isAbstract($name))) { /* throw error */ } } } ?> or <?php class Base { virtual public $x = 1; function __get($name) { if (!$this->isVirtual($name))) { /* throw error */ } } } ?> I prefer the 2nd, as it will not confuse with abstract classes (and it will definitely confuse users if we start mixing metaphors programmatically). I also prefer $this-> to self:: as it will allow (as James Crumpton raised) inheritance without redefinition of __get()/__set().

- Problem 3 can be solved by: * allowing optional by-ref parameters to the __set

    and __get function, so that their signatures become:

    function __set($name, $value [, &$error] )
    function __get($name [, &$error] )

If the parameter is not given things behave just like they do now -> __set and __get can not throw meaningful errors with the correct file/line of the conflicting statement If the parameter is used in the function's declaration and is set to "false" when the __set or __get function returns, the engine can throw an error on the assignment line with the correct file/line combination. If it's set to "true" (or "null") then the engine should not throw any error. * Use a different __set and __get function for 'abstract' properties, then

    the engine can already determine if you're doing something wrong before
    executing the __set and __get methods.

It seems to me the best solution would be to allow error to be set to false or an exception object, which would be then thrown as if it was on the offending line. This would allow the user to customize the error message as well as the line/file. Greg