Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
<?php
class some_base_class {}
?>
I can, sort of, think of this as ...
<?php
class some_base_class extends \stdClass {}
?>
in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
<?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?>
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
<?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?>
add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
