On 7/20/12 2:33 AM, "Anthony Ferrara" <ircmax...@gmail.com> wrote:
>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. I think I like it, as it is close to how I would proposed it before: Provide optional PHP6 type classes* and provide an fully oop api on them in line with other languages. But this is close enough, as it will give you possibility to explore available methods in IDE if you hint on type. And you avoid the total chaos you would get if new functions are introduced in global namespace. It doesn't automatically gives me strict type hinting possibilities in api's, but one step at a time.. :P One nitpic though: method names should be consistently formatted, and most methods in PHP (5+: DateTime, PDO, XML ...) and user land oop libraries is often ->lowerCamelCase(). * This is where that proposal is usually shoot down, at least it was by Rasmus and other internals. Argument being the added cost of objects, but is this the case in other implementations of PHP like HPHP? > >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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
