Property Overloading RFC

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.

<?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

I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?

regards,
Lukas

The whole point of these "virtual" properties is that their names can be
parameterized. If you have 1000 of these variables (in a DB or somewhere), how
would you declare them as "abstract" or "virtual"?

Then you don't do it - it's not a requirement... just an optional thing
(and ofcourse you can't do the __have_prop() thing then that you
suggested below.

This is ofcourse overly complicated. A better workable solution would be -
without breaking BC (suggestions for syntax here are very welcome):

[snip]

How about a __have_prop() method that you can call to find out if a certain
virtual property exists?

Works for me, but it needs to be able to called statically (::) and
dynamically (->).

Derick

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

Hi!

Sorry for wrong threading or if this solution was suggested before... i
currently don't have access to my mail client:)

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.

Don't know if this can be implemented... but what's about a 3rd boolean
"handled" call-by-reference-parameter which must be switched to "TRUE" if
the property could be handled? Should be TRUE if ommitted for bc reasons,
of course.

greets, Roland

...And, this could allow static member overloading as well!

-Justin

Justin Hannus wrote:

The way ActionScript 2.0 solves this is with set and get keywords on
function declarations. Any class can contain as many setter/getters as
they need,. Since we dont want to introduce any new keywords how about
something similar with __set and __get?

<?php

class Foo
{
private $_fooProp;

function __set fooProp($val)
{
    $this->_fooProp = $val; // $_fooProp is read only
}

function __set barProp($val)
{
    // logic to set barProp...
}

function __get barProp($val)
{
    // logic to get barProp...
}

}
?>

To allow for BC, if there is no identifier after the __set/__get then
the existing rules apply.

-Justin

Derick Rethans wrote:

Hello!

we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.

Introduction:
PHP currently supports property overloading with the magic functions
__get()
and __set(). Those methods are called when the code "echo $object->a" or
"$object->a = 42" are executed and the property "a" is not declared in
the
class. The magic methods are responsibly for:

• checking if the property actually "exists"
• setting the value or returning the value depending on the action

Problems:

1. There is no way to document the 'virtual' properties with any of
   the existing
   documentation tools (such as phpdoc and doxygen)
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).
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.

Solutions:

• For problem 1. we can introduce a keyword (or use an existing one)
  to define
  that it is a virtual property ('abstract' or 'virtual' come to
  mind). When
  declaring it like this it's easy to document, and we can also implement
  visibility for those virtual properties. Marcus already has a patch
  for
  this somewhere, which uses the "abstract" keyword for this purpose:

<?php
class Base
{
/**
* @var int Contains all X
*/
abstract public $x = 1;

/**
 * @var int   Contains all Y
 */
abstract protected $y = 2;

//  abstract private $z = 3; abstract properties cannot be private

}
?>

• In combination to the introduced keyword we need an easy way to
  check if a
  passed property name is declared in the class as 'virtual'.
  Currently (with
  the 'abstract' keyword properly implemented) you'd have to do:

<?php
class Base
{
abstract public $x = 1;

function __get($name)
{
    try {
        $prop = new ReflectionProperty('Base', $name);
        if ( !$prop->isAbstract() ) {
            /* throw error */
        }
    } catch ($e) {
        /* throw error */
    }
}

}

$b = new Base();
echo $b->foo;
?>

This is ofcourse overly complicated. A better workable solution
would be -
without breaking BC (suggestions for syntax here are very welcome):

<?php
class Base
{
abstract public $x = 1;

function __get($name)
{
    if (!self::isVirtual($name))) {
        /* throw error */
    }
}

}

$b = new Base();
echo $b->foo;
?>

• 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.

regards,
Derick

Please let me correct my last post, and sorry for the double posting :)

Justin Hannus wrote:

The way ActionScript 2.0 solves this is....

<?php

class Foo
{
private $_fooProp;

  function __get fooProp()
  {
      return $this->_fooProp; // $_fooProp is read only
  }

function __set barProp($val)
{
    // logic to set barProp...
}

  function __get barProp()
  {
      // logic to get barProp...
  }

}
?>

To allow for BC, if there is no identifier after the __set/__get then
the existing rules apply.

-Justin

Derick Rethans wrote:

Hello!

we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.

Introduction:
PHP currently supports property overloading with the magic functions
__get()
and __set(). Those methods are called when the code "echo $object->a" or
"$object->a = 42" are executed and the property "a" is not declared in
the
class. The magic methods are responsibly for:

• checking if the property actually "exists"
• setting the value or returning the value depending on the action

Problems:

1. There is no way to document the 'virtual' properties with any of
   the existing
   documentation tools (such as phpdoc and doxygen)
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).
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.

Solutions:

• For problem 1. we can introduce a keyword (or use an existing one)
  to define
  that it is a virtual property ('abstract' or 'virtual' come to
  mind). When
  declaring it like this it's easy to document, and we can also implement
  visibility for those virtual properties. Marcus already has a patch
  for
  this somewhere, which uses the "abstract" keyword for this purpose:

<?php
class Base
{
/**
* @var int Contains all X
*/
abstract public $x = 1;

/**
 * @var int   Contains all Y
 */
abstract protected $y = 2;

//  abstract private $z = 3; abstract properties cannot be private

}
?>

• In combination to the introduced keyword we need an easy way to
  check if a
  passed property name is declared in the class as 'virtual'.
  Currently (with
  the 'abstract' keyword properly implemented) you'd have to do:

<?php
class Base
{
abstract public $x = 1;

function __get($name)
{
    try {
        $prop = new ReflectionProperty('Base', $name);
        if ( !$prop->isAbstract() ) {
            /* throw error */
        }
    } catch ($e) {
        /* throw error */
    }
}

}

$b = new Base();
echo $b->foo;
?>

This is ofcourse overly complicated. A better workable solution
would be -
without breaking BC (suggestions for syntax here are very welcome):

<?php
class Base
{
abstract public $x = 1;

function __get($name)
{
    if (!self::isVirtual($name))) {
        /* throw error */
    }
}

}

$b = new Base();
echo $b->foo;
?>

• 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.

regards,
Derick

The way ActionScript 2.0 solves this is with set and get keywords on function
declarations. Any class can contain as many setter/getters as they need,.
Since we dont want to introduce any new keywords how about something similar
with __set and __get?

[...]

To allow for BC, if there is no identifier after the __set/__get then the
existing rules apply.

This is all way to complex.

Derick

we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.

I updated the proposal:
http://files.derickrethans.nl/property_overloading.html

If nobody as any better idea on how to solve it I'd like to start
implementing it.

Derick

-- Derick Rethans eZ systems | http://ez.no

--

This seems to be a good propals. IMO, it lacks just one thing - what
about property with a pulbic getter and protected setter for example?

Derick Rethans wrote:

I updated the proposal:
http://files.derickrethans.nl/property_overloading.html

If nobody as any better idea on how to solve it I'd like to start
implementing it.

I seem to remember that we had some voices here stating that the current
mechanisms are sufficient. Adding new keywords and/or new magic methods
is something which should have a very high threshold as it complicates
the language.

To me the proposal looks like a worst of both worlds kind of compromise:
Add new keywords and magic methods coupled with (ab)using the (in this
context somewhat inelegant) __get/__set mechanism.

So I'd rather not see this implemented to be honest.

• Chris

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? Should PHP somehow take care of that or is it
   responsibility of __get writer? How PHP should act on this - should it
   define entry in the hashtable or should it just ignore it? What
   protected/private means there too? Would PHP have to take care for
   inheritance and if so - how will it be enforced so that __get can't be
   called for protected property?

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 ;)

2. I don't like having to go to reflection for finding out if it's defined
   or not. 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.

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?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

I updated the proposal:
http://files.derickrethans.nl/property_overloading.html

#1)
It seems to me that after declaring the property with the property
keyword, the property isn't so virtual anymore.

#2)

I think this is a good idea, but aren't double underline methods
reserved for those called by PHP itself. The example shows the user
calling __have_prop(). Under what circumstances would php call
__have_prop()?

#3)

I would rather see an exception based mechanism for this, but I'll
concede that as unlikely, so i'll just suggest using the standard PHP
boolean values. The proposal implies TRUE & NULL would be the same,
which seems inconsistent.

Hello Derick,

Thursday, August 25, 2005, 2:01:56 PM, you wrote:

we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.

I updated the proposal:
http://files.derickrethans.nl/property_overloading.html

If nobody as any better idea on how to solve it I'd like to start
implementing it.

Instead of "__have_prop" can you make that "__has_prop" or "__exists" or
"__declared". "have" simply seems wrong thus (2). However that uses two
words which i don't like and so i cam to (3) and (4). Version (3) is better
than (4) because ArrayAccess also uses "exists".

Best regards,
Marcus

Derick Rethans wrote:

I updated the proposal:
http://files.derickrethans.nl/property_overloading.html

1. seems to be an issue in doxygen and phpDocumentor

2. this seems solveable with a non public set of arrays containing
   information about the property and its visibility ..

with a bit of hacking phpDocumentor could even read this information if
they/we decide on a suggested nameing standard. i dont see why we should
pollute the php language with this though

3. sounds like a great idea. we should also have something like this for
   __call().

regards,
Lukas

Hello Derick,

Thursday, August 25, 2005, 2:01:56 PM, you wrote:

we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.

I updated the proposal:
http://files.derickrethans.nl/property_overloading.html

If nobody as any better idea on how to solve it I'd like to start
implementing it.

To your solution of problem 3. We do not yet allow signatures of the
form (... [, ...]) since that would break our inheritance system.
The thing you could do is that the root class decides whetehr we have
that optional paramater always or never.

Best regards,
Marcus