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
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadling@gmail.comwrote:
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.
PHP does not support multiple inheritance. So no, this doesn't solve really
the issue.
Nikita
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadling@gmail.comwrote:
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.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.
So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.
And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.
On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadling@gmail.comwrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling <rquadling@gmail.com
wrote: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.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
Brandon Wamboldt
Software Engineer
Resume/CV http://brandonwamboldt.com/cv/ - Personal
Site/Bloghttp://brandonwamboldt.ca/
- LinkedIn http://ca.linkedin.com/in/brandonwamboldt - StackOverflow
Careers Profile http://careers.stackoverflow.com/brandonwamboldt - GitHub
Profile <https://github.com/brandonwamboldt
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadling@gmail.comwrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling <rquadling@gmail.com
wrote: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.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.Richard.
Ah. DOH!
Would having an interface that swapped the default property accessor logic
be any better?
So, I could say ...
<?php
class myBase implements \PHPMaintainedSetterGetterLogic {}
?>
Hmmm...
I know it is still not perfect.
Shame.
I really would have liked setter/getter.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
On Mon, Jun 3, 2013 at 10:30 AM, Richard Quadling rquadling@gmail.comwrote:
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.
[...]Ah. DOH!
Would having an interface that swapped the default property accessor logic
be any better?
Or a trait ("Accessable", "Accessored", "Accessorable")? Is it possible to
have a trait implemented internally? Though it seems that this would still
sometimes run afoul of mixing new accessor logic with old.
Hi Nikita
2013/6/3 Nikita Popov nikita.ppv@gmail.com:
PHP does not support multiple inheritance. So no, this doesn't solve really
the issue.
This is also why this makes a lot more sense to implement as an
Interface as we can implement more than one per class, much like we do
with ArrayAccess.
--
regards,
Kalle Sommer Nielsen
kalle@php.net