Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67612
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
Date: Mon, 3 Jun 2013 17:49:11 +0100
Message-ID: <CAKUjMCXWO2d_gR-tYKf0pBGqn9j0juqgYVhcw4rf528QL4hTng@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10d1dba6826204de42bfca
Subject: Random Monday thought.
From: rquadling@gmail.com (Richard Quadling)

--047d7b10d1dba6826204de42bfca
Content-Type: text/plain; charset=UTF-8

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

--047d7b10d1dba6826204de42bfca--