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
