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
