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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
