Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65290
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mrclay.org from 50.22.11.19 cause and error)
Message-ID: <5106D19C.4020506@mrclay.org>
Date: Mon, 28 Jan 2013 14:29:32 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Thoughts on "scalar objects"
From: steve@mrclay.org (Steve Clay)

Re: https://github.com/nikic/scalar_objects

Initial impression: This patch reminds me of extending native prototypes in Javascript, 
with similar limitations that may explain why this has fallen out of fashion in JS. The 
big one is that allowing change to the prototypes introduces global state with all the 
problems that implies. The second is that you can't store local state beside the value. 
E.g. a useful UTF-8 string class would want to store some extra state like: has the string 
been validated, and are all chars in ASCII.

Other ideas:

* Instead of registering a single class to wrap a native type, allow users to register 
handlers that receive the native value, the type, the called method name, and args. This 
allows altering behavior based on the value/method at call-time. The handler would return 
a 2 member array: the first would indicate whether the handler actually handled the call, 
the second would have the return value.

* Would it be possible to limit this behavior to a particular scope?


Steve Clay
-- 
http://www.mrclay.org/