The only "open comments" I have on this project is the "read-only" and "write-only" keywords.
Are the dashes acceptable or undesirable?
write-only was not in the original RFC but made sense to have the alternate to read-only, any objections?
If there is no other discussion for this, I'd like to move this to the voting phase, any objects?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
-Clint
Hi!
If there is no other discussion for this, I'd like to move this to the voting phase, any objects?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Sorry, I didn't have time to look into it yet (yes I know it was around
for a long time...) in detail. From the quick glance I don't like the
read-only/write-only keywords too much but maybe it's ok.
It's not clear what "automatic implementation" is. Could you expand this
section and add explanation what actually happens?
What would happen if I use $this->property &= $a; or $a &=
$this->property; $a = 1;?
What happens if getter/setter function uses the same property it is
defined for? What if it uses other property that in turn uses this one?
In the last example for overloading, it looks like
"parent::$Milliseconds = $value;" calls parent setter. This looks like
static property access but is not. I don't think it's a good thing. What
if you also have static class var called $Milliseconds? And especially
that later you introduce the same syntax for accessing class properties!
How these would work with isset - what !empty($this->Hours) return? What
would happen if you do unset($this->Hours)? What happens if you do
$this->Hours++ or sort($this->Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC too.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2012/4/20 Stas Malyshev smalyshev@sugarcrm.com:
How these would work with isset - what !empty($this->Hours) return? What
would happen if you do unset($this->Hours)? What happens if you do
$this->Hours++ or sort($this->Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC too.
My suggestion is to support the same methods for properties as we do
for magic class methods: __set, __get, __isset and __unset.
All the other operations (sort, ++, <<,...) should behave exactly as
if it was be implemented with current magic class methods with a usual
switch/case statement.
isset/unset property hooks
I could definitely see having the isset and unset hooks as well, anyone disagree with that? I would expect them to syntactically show up as such:
public $Hours {
get { ... }
set { ... }
isset { return true; /* returns bool / }
unset { unset(...); / returns void */ }
}
Thoughts?
Operators
I've tested with a number of the operators and they are all working as expected. I have updated the RFC to reflect that. I will also write tests for reference access as well as with some functions such as sort(), is_*(), empty() and some others.
Other suggestions on functions we should write tests for?
read-only/write-only
There are people on both sides of the fence, where do I go from here, put it up for a specific vote?
parent∷ scope access
For the parent::$Milliseconds comment by Stanislav. This was in the original RFC and I think it fits well since it's the same syntax that would be used in a function to access a parent function, such as function a() { /* ... */ return parent::a(); } Though I have not used the parent::$xxx to access static values myself I know it's possible. Right now using parent:: format would first look for a parent accessor, then a parent static accessor, then would follow normal functionality, to access a parent static reference. I've documented this in the RFC under Overloading Properties now.
What other format/keyword would make as much sense as parent::?
-Clint
-----Original Message-----
From: patrick.allaert@gmail.com [mailto:patrick.allaert@gmail.com] On Behalf Of Patrick ALLAERT
Sent: Friday, April 20, 2012 5:36 AM
To: Stas Malyshev
Cc: Clint M Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
2012/4/20 Stas Malyshev <smalyshev@sugarcrm.commailto:smalyshev@sugarcrm.com>:
How these would work with isset - what !empty($this->Hours) return?
What would happen if you do unset($this->Hours)? What happens if you
do $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC too.
My suggestion is to support the same methods for properties as we do for magic class methods: __set, __get, __isset and __unset.
All the other operations (sort, ++, <<,...) should behave exactly as if it was be implemented with current magic class methods with a usual switch/case statement.
How these would work with isset - what !empty($this->Hours) return? What would happen if you do unset($this->Hours)? What happens if you do $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC too.
So I've just tested these things and the accessors perform the same way as with __get()/__set().
empty() - Returns true for a property retrieved via __get() or via a getter -- Any idea why this would be the case for __get()? Is this a bug?
unset() - Would unset a temporary variable (the one returned by the getter) -- see previous email re: adding unset/isset property functions.
sort() - Does the same thing as with __get()/__set() which is to say, the array is sorted but the property is not updated with the value. Should accessor behave differently than the magic methods? Should this just be documents or should this be fixed?
-Clint
Hi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?
isset() calls __isset(), empty() calls __isset() and __get(). I'm not
sure what exactly you consider to be a bug.
unset() - Would unset a temporary variable (the one returned by the
getter) -- see previous email re: adding unset/isset property
functions.
unset() calls __unset().
sort()- Does the same thing as with __get()/__set() which is to say,
the array is sorted but the property is not updated with the value.
Should accessor behave differently than the magic methods? Should
this just be documents or should this be fixed?
sort() works just fine if you define __get to return by-ref.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Saturday, April 21, 2012 10:33 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntaxHi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure what exactly you consider to be a bug.
I see, well the only way to resolve this would be to add isset and unset property functions as well.
Anyone against it?
unset() - Would unset a temporary variable (the one returned by the
getter) -- see previous email re: adding unset/isset property
functions.unset() calls __unset().
sort()- Does the same thing as with __get()/__set() which is to say,
the array is sorted but the property is not updated with the value.
Should accessor behave differently than the magic methods? Should
this just be documents or should this be fixed?
sort()works just fine if you define __get to return by-ref.
Returning by reference was not documented in the original RFC, would this syntax work for everyone?
public $Hours {
&get { return $this->a; }
}
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
What is the state here with regard to merge into php-src?
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Saturday, April 21, 2012 10:33 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntaxHi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?isset() calls __isset(), empty() calls __isset() and __get(). I'm not
sure what exactly you consider to be a bug.I see, well the only way to resolve this would be to add isset and unset
property functions as well.Anyone against it?
unset() - Would unset a temporary variable (the one returned by the
getter) -- see previous email re: adding unset/isset property
functions.unset() calls __unset().
sort()- Does the same thing as with __get()/__set() which is to say,
the array is sorted but the property is not updated with the value.
Should accessor behave differently than the magic methods? Should
this just be documents or should this be fixed?
sort()works just fine if you define __get to return by-ref.Returning by reference was not documented in the original RFC, would this
syntax work for everyone?public $Hours {
&get { return $this->a; }
}--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I've just recently had my second child and closed on a new house, so been a bit busy. I'll be working to finish up what's left in the coming weeks.
Right now I'm told there are some conflicts with a merge from master that I have to resolve, then the fork will be ready for playing around with. Hopefully I'll have that fixed up later this week.
From: Benjamin Eberlei [mailto:kontakt@beberlei.de]
Sent: Thursday, June 28, 2012 4:55 AM
To: Clint Priest
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
What is the state here with regard to merge into php-src?
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.commailto:smalyshev@sugarcrm.com]
Sent: Saturday, April 21, 2012 10:33 PM
To: Clint M Priest
Cc: internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntaxHi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure what exactly you consider to be a bug.
I see, well the only way to resolve this would be to add isset and unset property functions as well.
Anyone against it?
unset() - Would unset a temporary variable (the one returned by the
getter) -- see previous email re: adding unset/isset property
functions.unset() calls __unset().
sort()- Does the same thing as with __get()/__set() which is to say,
the array is sorted but the property is not updated with the value.
Should accessor behave differently than the magic methods? Should
this just be documents or should this be fixed?
sort()works just fine if you define __get to return by-ref.
Returning by reference was not documented in the original RFC, would this syntax work for everyone?
public $Hours {
&get { return $this->a; }
}
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227<tel:%28408%29454-6900%20ext.%20227
Hi all,
Has array access been considered for properties? I can see a good use
for this for cross-referencing objects.
class Parent
{
private $_children = array();
public $children {
offsetSet { $value->parent = $this; $this->_children[$key] = $value; }
offsetUnset { $value->parent = null; unset($this->_children[$key]; }
// etc.
}
}
$parent = new Parent();
$child = new Child();
$parent->children[] = $child;
// $child->parent === $parent
Cheers,
Bernhard
2012/7/9 Clint Priest cpriest@zerocue.com:
I've just recently had my second child and closed on a new house, so been a bit busy. I'll be working to finish up what's left in the coming weeks.
Right now I'm told there are some conflicts with a merge from master that I have to resolve, then the fork will be ready for playing around with. Hopefully I'll have that fixed up later this week.
From: Benjamin Eberlei [mailto:kontakt@beberlei.de]
Sent: Thursday, June 28, 2012 4:55 AM
To: Clint Priest
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntaxWhat is the state here with regard to merge into php-src?
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.commailto:smalyshev@sugarcrm.com]
Sent: Saturday, April 21, 2012 10:33 PM
To: Clint M Priest
Cc: internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntaxHi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure what exactly you consider to be a bug.
I see, well the only way to resolve this would be to add isset and unset property functions as well.Anyone against it?
unset() - Would unset a temporary variable (the one returned by the
getter) -- see previous email re: adding unset/isset property
functions.unset() calls __unset().
sort()- Does the same thing as with __get()/__set() which is to say,
the array is sorted but the property is not updated with the value.
Should accessor behave differently than the magic methods? Should
this just be documents or should this be fixed?
sort()works just fine if you define __get to return by-ref.
Returning by reference was not documented in the original RFC, would this syntax work for everyone?public $Hours {
&get { return $this->a; }
}--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227<tel:%28408%29454-6900%20ext.%20227
Hi,
Are the dashes acceptable or undesirable?
I think without dashes it is more in line with other keywords, like "instanceof" or "insteadof".
Because keywords are not case sensitive, one who likes them to be more readable could write them camelCased, for example "readOnly", or "writeOnly".
--
Christoph Hochstrasser
http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH
Hi,
Are the dashes acceptable or undesirable?
I think without dashes it is more in line with other keywords, like
"instanceof" or "insteadof".Because keywords are not case sensitive, one who likes them to be more
readable could write them camelCased, for example "readOnly", or
"writeOnly".
If they are to be keywords, I'd argue we should use the dash variant --
the reason being that with the dash, there can be no conflict with
existing constant, variable, or function names. I know I've had a fair
number of each named both "readonly" and "writeonly".
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc