Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On Fri, Jan 11, 2013 at 8:08 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion,
is this supposed to already get the value of the property (and there
would be an additional method ReflectionProperty::setParentProperty)?
I meant getting the ReflectionProperty class, but getting the actual
value is an option too. Of course, then it should be method on
ReflectionPropertyAccessor, since regular properties don't have this
thing. I'm not sure which is better - it depends on how much this would
be used. We could even not do anything special at all - as I said,
current reflection already has API to allow doing exactly this (well,
after property support is added), even if a bit long-winded.
The current property can be obtained through
EG(current_execute_data)-function_state.function. This holds the
accessor function and the property can be taken from its name. Though
this is obviously all a bit dirty and is probably not a good idea.
Probably better to let people explicitly pass the property name.
I agree. That's why I also mentioned having __PROPERTY__ - this makes
copypasting methods a bit easier since you have less chances of making
typo in property names :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did
seem like a very nice feature to have.
I don't know if it is very helpful but posting nevertheless. I'm a
C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2
document makes perfect sense and is intuitive to use. As for the
earlier example about isset...
i'd expect an example like this:
class SomeClass {
public $date {
get;
set(DateTime $date);
}
}
$temp = new SomeClass();
i'd expect isset($temp-date) to return exactly the same as if the
class where defined like this:
class SomeClass {
public $date;
}
I don't know if that issue was already sorted out but i wanted to
share my expectations in that regards.
Will this make PHP 5.5? Or will it be deferred to 5.6?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On 1/13/2013 8:01 AM, Mark wrote:
I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did
seem like a very nice feature to have.
I don't know if it is very helpful but posting nevertheless. I'm a
C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2
document makes perfect sense and is intuitive to use. As for the
earlier example about isset...
i'd expect an example like this:
class SomeClass {
public $date {
get;
set(DateTime $date);
}
}
$temp = new SomeClass();
i'd expect isset($temp-date) to return exactly the same as if the
class where defined like this:
class SomeClass {
public $date;
}
That's correct, it will.
Furthermore, isset() will never throw an error, even if it would not be
legal to call isset or get (from 1.1 RFC changes).
I don't know if that issue was already sorted out but i wanted to
share my expectations in that regards.
Will this make PHP 5.5? Or will it be deferred to 5.6?
Nikita, Stas and I are working very hard to make it into 5.5, we expect
to propose a vote sometime in the next couple of days.
** Any remaining feedback is appreciated, the RFC is being kept up to
date w/ current understood consensus. **
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest cpri...@zerocue.com wrote:
Agreed. Some people may actually be using $parent as a variable name, not
difficult to imagine.
So far parent-foo seems to be the answer.
-Clint
My thoughts on the parent situations, as I'm not yet satisfied with the
current solution.
1) I tried to understand how the engine currently compiles and executes
object property fetches. I found it to be incredibly complex and I
certainly don't have the abilities to port this for statics. As such the
parent::$foo syntax is dead unless someone else is going to do the
necessary engine changes.
2) I think the parent-foo syntax is nice in concept, but I think that
it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
still require some engine changes those complexity I can't really
estimate). The parent-foo syntax is some off mix between parent::$foo
(which makes sense) and $parent-foo (which also makes sense). parent-foo
combines it in an odd way that doesn't look like PHP and adds yet another
new syntax for something that's going to be a rare case anyway.
3) My suggestion is to avoid the engine and syntax related issues of parent
property access by putting this as a function in the standard library
instead. What I'm thinking about is a function like get_parent_property()
which returns the ReflectionProperty for it. Then you could do something
like this:
public $foo {
get { return 'parent is: ' .
get_parent_property('foo')-getValue(); }
set($val) { get_parent_property('foo')-setValue($val . '
something'); }
}
I know that this is not an optimal solution, but I would much prefer this
over some new syntax like parent-foo. Once (if) static properties have
better engine support we can switch to the cleaner parent::$foo way. But
until then I think that this is a good compromise, especially considering
that accessing the parent property shouldn't be a very common operation, so
it's okay if it's a bit more verbose.
This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could not
return a ReflectionProperty and instead provide two functions
get_parent_property and set_parent_property (what about isset and unset in
that case though?)
So, what do you think about this?
Nikita
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi!
1) I tried to understand how the engine currently compiles and executes
object property fetches. I found it to be incredibly complex and I
certainly don't have the abilities to port this for statics. As such the
parent::$foo syntax is dead unless someone else is going to do the
necessary engine changes.
Object property fetches are not that hard, but parent::$foo is static
fetch - which is entirely different beast which uses different opcodes
and works differently. And is not supported by object handlers - mainly
because there's no object :) If we designed it from scratch, we could
probably make a class an object of type Class and probably avoided that
problem, since we could just use standard object handlers for that, but
it is not what currently happens. If somebody feels ambitious he may
explore that direction.
2) I think the parent-foo syntax is nice in concept, but I think that
it's an absolute no-go as it doesn't fit in with the rest of PHP (and
Well, it partially does, since -foo part works exactly like in any
other expression. But parent- part and the whole dollar-less variable
seems foreign for me too, so I am not happy with this one either.
would still require some engine changes those complexity I can't really
estimate). The parent-foo syntax is some off mix between parent::$foo
(which makes sense) and $parent-foo (which also makes sense).
$parent-foo makes tons of sense, but it means there's an object called
$parent. Now the question is where this one came from?
3) My suggestion is to avoid the engine and syntax related issues of
parent property access by putting this as a function in the standard
library instead. What I'm thinking about is a function like
get_parent_property() which returns the ReflectionProperty for it. Then
you could do something like this:
This is an interesting approach. I like the idea of using the reflection
instead of inventing an awkward new syntax. However, I'm not sure I can
see how get_parent_property('foo') works - what exactly is 'foo' here?
Does it mean this function relies on implied $this? I'm not sure we
should be adding functions that do this. I'd rather have something like:
ReflectionProperty::getParentProperty($this, 'foo')
And yes, I know it's long-winded. But on the plus since it's generic,
does not pollute global space and might also be useful in other contexts.
Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):
(new ReflectionProperty(get_parent_class(), 'foo'))-setValue($this, $val);
Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.
I know that this is not an optimal solution, but I would much prefer
this over some new syntax like parent-foo. Once (if) static
I like this approach more too.
properties have better engine support we can switch to the cleaner
parent::$foo way. But until then I think that this is a good compromise,
I'm afraid we couldn't though since parent::$foo already means something
else - it's a static property $foo of the class that is parent of
current class. We could redefine it in this specific context, in theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has only one
class and all properties belong to this class, so we don't have a proper
syntax to express the idea of same property, but with different scope.
This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could
If you assume current property you'd have to store it somewhere to pass
it and have API for that function to extract it, which sounds like very
tight coupling for this function. Maybe something like __PROPERTY__
would be better?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On Fri, Jan 11, 2013 at 1:03 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
3) My suggestion is to avoid the engine and syntax related issues of
parent property access by putting this as a function in the standard
library instead. What I'm thinking about is a function like
get_parent_property() which returns the ReflectionProperty for it. Then
you could do something like this:
This is an interesting approach. I like the idea of using the reflection
instead of inventing an awkward new syntax. However, I'm not sure I can
see how get_parent_property('foo') works - what exactly is 'foo' here?
Does it mean this function relies on implied $this?
I wrote that without actually checking the Reflection API, I forget that
one has to pass the object too. So my code samples should rather look like
this:
get_parent_property('foo')-getValue($this);
get_parent_property('foo')-setValue($this, ...);
And yes, I know it's long-winded. But on the plus since it's generic,
does not pollute global space and might also be useful in other contexts.
Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion, is
this supposed to already get the value of the property (and there would be
an additional method ReflectionProperty::setParentProperty)?
Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):
(new ReflectionProperty(get_parent_class(), 'foo'))-setValue($this, $val);
Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.
I know that this is not an optimal solution, but I would much prefer
this over some new syntax like parent-foo. Once (if) static
I like this approach more too.
properties have better engine support we can switch to the cleaner
parent::$foo way. But until then I think that this is a good compromise,
I'm afraid we couldn't though since parent::$foo already means something
else - it's a static property $foo of the class that is parent of
current class. We could redefine it in this specific context, in theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has only one
class and all properties belong to this class, so we don't have a proper
syntax to express the idea of same property, but with different scope.
I try to see :: as a scope resolution operator rather than a static access
operator. For methods that's how it works (you can call instance methods
with it in a different scope, e.g. parent scope). So doing the same for
properties isn't far off. But yes, I do agree that this would be rather
tricky and could open another big can of worms (like we have with method
calls from incompatible contexts), so it might not actually make sense to
go down that path.
This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could
If you assume current property you'd have to store it somewhere to pass
it and have API for that function to extract it, which sounds like very
tight coupling for this function. Maybe something like __PROPERTY__
would be better?
The current property can be obtained through
EG(current_execute_data)-function_state.function. This holds the accessor
function and the property can be taken from its name. Though this is
obviously all a bit dirty and is probably not a good idea. Probably better
to let people explicitly pass the property name.
Nikita
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Why we must have parent property access at all? What's the use case and how do
other langs do it?
Am I right to say there is no parent property, this would just call the
parent's [gs]etter using the same underlying property value?
Steve
--
http://www.mrclay.org/
On Jan 10, 2013, at 6:15 PM, Nikita Popov nikita@gmail.com wrote:
On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest cpri...@zerocue.com wrote:
Agreed. Some people may actually be using $parent as a variable name, not
difficult to imagine.
So far parent-foo seems to be the answer.
-Clint
My thoughts on the parent situations, as I'm not yet satisfied with the
current solution.
1) I tried to understand how the engine currently compiles and executes
object property fetches. I found it to be incredibly complex and I
certainly don't have the abilities to port this for statics. As such the
parent::$foo syntax is dead unless someone else is going to do the
necessary engine changes.
2) I think the parent-foo syntax is nice in concept, but I think that
it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
still require some engine changes those complexity I can't really
estimate). The parent-foo syntax is some off mix between parent::$foo
(which makes sense) and $parent-foo (which also makes sense). parent-foo
combines it in an odd way that doesn't look like PHP and adds yet another
new syntax for something that's going to be a rare case anyway.
3) My suggestion is to avoid the engine and syntax related issues of parent
property access by putting this as a function in the standard library
instead. What I'm thinking about is a function like get_parent_property()
which returns the ReflectionProperty for it. Then you could do something
like this:
public $foo {
get { return 'parent is: ' .
get_parent_property('foo')-getValue(); }
set($val) { get_parent_property('foo')-setValue($val . '
something'); }
}
I know that this is not an optimal solution, but I would much prefer this
over some new syntax like parent-foo. Once (if) static properties have
better engine support we can switch to the cleaner parent::$foo way. But
until then I think that this is a good compromise, especially considering
that accessing the parent property shouldn't be a very common operation, so
it's okay if it's a bit more verbose.
This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could not
return a ReflectionProperty and instead provide two functions
get_parent_property and set_parent_property (what about isset and unset in
that case though?)
So, what do you think about this?
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On 1/10/2013 6:57 PM, Nikita Popov wrote: Even more generic, we just could use existing ReflectionProperty like this (this is standard API, no changes needed): (new ReflectionProperty(get_parent_class(), 'foo'))-setValue($this, $val); Yes, this is even more long-winded, that's why maybe we should have shortcut function for it. Depends on how frequently in practice we expect to do it. I like this idea as a solution to the problem. It would be ideal if parent::$foo would work but since that is not currently a reasonable option, either leaving the user land programmer to use reflection to do it or to provide them with a shortcut way to do it is a good interim solution to the problem. I'm not sure that we really even need a 'shortcut' to do it, we'd need some other people to chime in on that and how often the parent accessor would want to be called. I know that this is not an optimal solution, but I would much prefer this over some new syntax like parent-foo. Once (if) static I like this approach more too. +1 as well properties have better engine support we can switch to the cleaner parent::$foo way. But until then I think that this is a good compromise, I'm afraid we couldn't though since parent::$foo already means something else - it's a static property $foo of the class that is parent of current class. We could redefine it in this specific context, in theory, but that would be strange special case and I don't think it would be good idea to do that. Our syntax kind of assumes the object has only one class and all properties belong to this class, so we don't have a proper syntax to express the idea of same property, but with different scope. I try to see :: as a scope resolution operator rather than a static access operator. For methods that's how it works (you can call instance methods with it in a different scope, e.g. parent scope). So doing the same for properties isn't far off. But yes, I do agree that this would be rather tricky and could open another big can of worms (like we have with method calls from incompatible contexts), so it might not actually make sense to go down that path. I agree with that general sentiment as :: as a scope resolution operator, it's just that right now, for ::$ that always translates to static property access which is the current conundrum. This is just a rough idea of what I'd do. The exact way this would work still needs further discussion. E.g. one could make passing the property name optional and assume the current property as default. Or one could If you assume current property you'd have to store it somewhere to pass it and have API for that function to extract it, which sounds like very tight coupling for this function. Maybe something like __PROPERTY__ would be better? The current property can be obtained through EG(current_execute_data)-function_state.function. This holds the accessor function and the property can be taken from its name. Though this is obviously all a bit dirty and is probably not a good idea. Probably better to let people explicitly pass the property name. Nikita Is everyone okay with a long winded way to get/set the parent accessor if necessary? (new ReflectionProperty(get_parent_class(), 'foo'))-setValue($this, $val); Alternatively, reflection in some cases takes an object instance (ReflectionObject), we could extend ReflectionPropertyAccessor so that it could take an object, then something that is slightly shortened would work, like this: (new ReflectionPropertyAccessor($this, 'foo'))-setValue(45); That presently doesn't work, but could be made to work, especially considering it's a new sub-class anyways. If we don't like setValue() being different b/w ReflectionProperty and ReflectionPropertyAccessor we could upgrade both classes to accept an object instance as its constructor argument... -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi! Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion, is this supposed to already get the value of the property (and there would be an additional method ReflectionProperty::setParentProperty)? I meant getting the ReflectionProperty class, but getting the actual value is an option too. Of course, then it should be method on ReflectionPropertyAccessor, since regular properties don't have this thing. I'm not sure which is better - it depends on how much this would be used. We could even not do anything special at all - as I said, current reflection already has API to allow doing exactly this (well, after property support is added), even if a bit long-winded. The current property can be obtained through EG(current_execute_data)-function_state.function. This holds the accessor function and the property can be taken from its name. Though this is obviously all a bit dirty and is probably not a good idea. Probably better to let people explicitly pass the property name. I agree. That's why I also mentioned having __PROPERTY__ - this makes copypasting methods a bit easier since you have less chances of making typo in property names :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) I actually proposed parent-foo. parent-$foo implies the name of the variable is $foo, not foo - just as in $this-$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Speaking of which, parent::foo ( with :: but no $) might work as well, almost *any* character change could work... parent:::$foo parent:$foo parent-$foo parent-foo parent.$foo parent.foo I favor having the $ in some solution though... -Clint On Jan 4, 2013, at 5:04 AM, Clint Priest cpri...@zerocue.com wrote: Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) I actually proposed parent-foo. parent-$foo implies the name of the variable is $foo, not foo - just as in $this-$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi Clint, Am 04.01.2013 um 04:13 schrieb Clint Priest cpri...@zerocue.com: [...] 1) It forces the user to access the parent property accessor in a different way than is used everywhere else Isn’t that the same as parent-$foo? Please let’s not introduce a special syntax for something that can be done properly. I would either go with variant 2 (Rewrite the way static property references work). If that takes too long and we feel that a version without parent access is sufficient, we should disallow parent access for version 1 of property accessors. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Uhm.. brain fart. I was thinking $this-$foo was normal when I wrote this up, I would change my last statement from the earlier email to any syntax which did not include a $. That being said then, I think I favor parent-foo the best. One other possible alternative would be to treat parent like a variable... $parent-foo On 1/4/2013 5:09 AM, Clint Priest wrote: Speaking of which, parent::foo ( with :: but no $) might work as well, almost *any* character change could work... parent:::$foo parent:$foo parent-$foo parent-foo parent.$foo parent.foo I favor having the $ in some solution though... -Clint On Jan 4, 2013, at 5:04 AM, Clint Priest cpri...@zerocue.com wrote: Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) I actually proposed parent-foo. parent-$foo implies the name of the variable is $foo, not foo - just as in $this-$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi Clint, got it. Am 04.01.2013 um 16:28 schrieb Clint Priest cpri...@zerocue.com: Uhm.. brain fart. I was thinking $this-$foo was normal when I wrote this up, I would change my last statement from the earlier email to any syntax which did not include a $. That being said then, I think I favor parent-foo the best. It’s not really a matter of syntax, but a matte of principle. We shouldn’t burden our users with another syntax to achieve the same thing. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi! One other possible alternative would be to treat parent like a variable... $parent-foo That would be a big BC problem and also require serious changes to handle it (look how $this is implemented - it's not regular variable at all). So $parent is probably a non-starter. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Agreed. Some people may actually be using $parent as a variable name, not difficult to imagine. So far parent-foo seems to be the answer. -Clint On 1/4/2013 4:23 PM, Stas Malyshev wrote: Hi! One other possible alternative would be to treat parent like a variable... $parent-foo That would be a big BC problem and also require serious changes to handle it (look how $this is implemented - it's not regular variable at all). So $parent is probably a non-starter. -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Note, there has been a show stopper of an issue with the current RFC that many minds have been talking about how to solve. The problem is with parent::$foo accessing the parent accessor. In summary, the difficulty is that this is parsed as a static property access and during compilation there is no guarantee that the parent class structure can be accessed (to confirm/deny that it's really an accessor and not a static property reference). This guarantee is not possible because you can define the parent class after the subclass. So... on to solutions that have been discussed and shot down. 1) Change the zend opcodes for static property references to identify the true state at run-time. This would be a hack to be certain and has been shot-down for that exact reason. This is also the reason that static accessors has been abandoned for this first iteration of the feature, because static properties are handled entirely differently from object based properties. 2) Rewrite the way static property references work, such that they make calls into zend_object_handler.c, which is probably something that should be done anyways as a separate RFC and project, at which point this problem would probably be trivial to solve. 3) Introduce a new opcode which could somehow solve this problem by introducing an additional step to determine whether its a parent accessor reference or a static property reference. This would also be hackish because the proper solution is #2 and beyond the scope of this RFC. A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) Pros: - It should not have any problems being implemented - It would move this RFC to completion Cons: - It does create an inconsistency in that nowhere else (that I know of) does parent-$foo do something. It may also sound like it should work because parent::__construct() works just fine, but that works fine because it goes through a different opcode system than static accessors do. Really, other than doing something like the above, the only other way would be for a getter to access it's parent by calling the function directly, such as parent::__getFoo() but this is undesirable for a number of reasons: 1) It forces the user to access the parent property accessor in a different way than is used everywhere else 2) It forces the user to utilize an underlying implementation detail that is not guaranteed to stay the same (it may change) 3) It's certainly not as syntactically nice as parent-$foo would be. As a final alternative to this problem, we could simply not allow a parents accessor to be used, which I think is probably the worst choice of all. Thoughts? There is a github ticket discussing this issue as well here if you'd like to chime in there on some more technical conversation about this issue: https://github.com/cpriest/php-src/issues/8 If anyone can think of any other way to solve this such that parent::$foo could work, I'm all ears but I'm out of ideas on this one and I think Stas's idea is just fine. On 1/2/2013 5:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 I'm posting it for final review so I can move to voting on Jan 7th. Please note that the current fork is not quite up-to-date with the RFC but will be within a few more days. -Clint -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi! A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) I actually proposed parent-foo. parent-$foo implies the name of the variable is $foo, not foo - just as in $this-$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
