Hello Greg,
Wednesday, August 3, 2005, 4:56:26 AM, you wrote:
> 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".
How about lazy initialization? You cannot have a declared property for those
atm.
> 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).
You would need to add another keyword for no reason.
> I also prefer $this-> to self:: as it will allow (as James Crumpton
> raised) inheritance without redefinition of __get()/__set().
I prefer here using property_is_virtual($this, $name).
>>
>> - 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.
I suggested exceptions but they are not always acceptable and overcomplicate
many things too much and finally come with some danger.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
