Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5008A1AE.9090404@sugarcrm.com>
References: <64223D01-8F4C-4B65-AD6C-5C425EC0EA68@gmail.com>
	<5008A1AE.9090404@sugarcrm.com>
Date: Thu, 19 Jul 2012 20:33:58 -0400
Message-ID: <CAAyV7nEFNE73imqUFfqx+y1kfwagcR2JTi8FmESefwEvTUppfA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Alexey Zakhlestin <indeyets@gmail.com>, internals internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf300fb50343ec3804c5380da5
Subject: Re: [PHP-DEV] Regarding PHP6, string/array APIs
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf300fb50343ec3804c5380da5
Content-Type: text/plain; charset=ISO-8859-1

Hey all,

So I've been thinking about this for a while. Here's what I've come up with:

1. We want to maintain loose typing, so implementing a different API on
string than on int types would be bad.

2. We want to retain backwards compatibility to some extent with the legacy
API.

3. We want the ability to simplify the standard library.

So here's my thought. Make $var->method($arg1, $arg2) on scalar types a
"short-hand" for \php\method($var, $arg1, $arg2).

So we re-organize the base API into \php, cut down to just the base
methods. So:

\php\length()
 - If array, count(), else strlen()
\php\substr()
 - Treat as string always
\php\replace()
 - Normal str_replace semantics
\php\split()
 - Treat as string always
\php\join()
 - Treat as array always
\php\shuffle()
 - If array, array_shuffle, otherwise str_shuffle
\php\pos()
 - if array, array_search(), else strpos()
\php\reverse()
 - if array, array_reverse(), else strrev()
\php\merge()
 - If array, array_merge, if not, string concat
\php\type()
 - return type information about variable
etc

Now, those that are clearly type specific, or are too specialized to belong
on a "global" type, would then be sub-namespaced:

\php\array\map()
\php\array\keys()
\php\math\min()
\php\math\max()
\php\math\round()
\php\string\number_format()
\php\string\chr()
\php\string\ord()
etc.

The benefit here, is that user types can implement the same "core"
interface and be used polymorphically with the core types (for at least the
base API). So then, countable() would disappear.

Now, there's one more thing that needs to happen. If you call
\php\length($var) directly (procedurally, not as a method call), we'd need
to check if $var is an object that implements ->length(), and if so, call
to that instead of an error.

That's the base idea. It could be extended further to include true objects
for scalars, which would implement the rest of the core API. So, you could
do:

(new \php\Array($array))->keys();

This would then assume standard object semantics for the "wrapped" type,
while at the same time losing the dynamic typing ability of the language
(but it's done on purpose here to keep the API clean).

For BC, we'd need to modify zend_parse_parameters to extract the array from
a wrapped array object, to keep BC code functioning correctly in either
case, but it should be pretty transparent to the user which is passed...

Is it perfect? Absolutely not. But it tries to get around the BC breaks, as
well as the dynamic typing issue that ints can be strings, and vise versa.

Thoughts?

Anthony

--20cf300fb50343ec3804c5380da5--