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