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 <rquadl...@gmail.com>wrote: > On 3 June 2013 17:55, Nikita Popov <nikita....@gmail.com> wrote: > > > On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling <rquadl...@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/Blog<http://brandonwamboldt.ca/> - LinkedIn <http://ca.linkedin.com/in/brandonwamboldt> - StackOverflow Careers Profile <http://careers.stackoverflow.com/brandonwamboldt> - GitHub Profile <https://github.com/brandonwamboldt>