# Random Monday thought. - Thread: https://externals.io/message/67612 - Original archive: https://news-web.php.net/php.internals/67612 - Started by Richard Quadling on 2013-06-03T16:49:11+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #67612 — Richard Quadling — 2013-06-03T16:49:11+00:00 URL: https://externals.io/message/67612#67612 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 ... I can, sort of, think of this as ... 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 ... 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 ... 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 --- ## #67613 — Nikita Popov — 2013-06-03T16:55:17+00:00 URL: https://externals.io/message/67612#67613 · In reply to: #67612 On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling 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 ... > > class some_base_class {} > ?> > > I can, sort of, think of this as ... > > 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 ... > > 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 ... > > 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 --- ## #67615 — Richard Quadling — 2013-06-03T17:20:15+00:00 URL: https://externals.io/message/67612#67615 · In reply to: #67613 > On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling wrote: > > > […] > > 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 --- ## #67616 — Brandon Wamboldt — 2013-06-03T17:22:09+00:00 URL: https://externals.io/message/67612#67616 · In reply to: #67615 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 wrote: > > > > […] > fact, > > […] > way > > […] > > > 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 - Personal Site/Blog - LinkedIn - StackOverflow Careers Profile - GitHub Profile : > 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 --- ## #67618 — Richard Quadling — 2013-06-03T17:30:37+00:00 URL: https://externals.io/message/67612#67618 · In reply to: #67616 > 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 wrote: > > > […] > Ah. DOH! Would having an interface that swapped the default property accessor logic be any better? So, I could say ... 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 --- ## #67619 — Galen Wright-Watson — 2013-06-03T19:14:28+00:00 URL: https://externals.io/message/67612#67619 · In reply to: #67618 On Mon, Jun 3, 2013 at 10:30 AM, Richard Quadling wrote: > > > > […] > 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.