Re: I think that "Function naming inconsistency" bug deservers more attention

> https://github.com/nikic/scalar_objects I think register_primitive_type_handler() is too exclusive: When I use 2 frameworks in the same code base, one might do register_primitive_type_handler('string', 'A\StringHandler') and the other might do register_primitive_type_handler('string', 'B\StringHandler') in the bootstrap. The result will be only the second one is working. Also I see more variations instead of a cleanup. Working with an IDE, register_primitive_type_handler requires type hints to use auto completion: register_primitive_type_handler('string', 'StringHandler'); /* @var $str StringHandler */ $str = 'foobar'; echo $str->length(); vs. $str = new StringHandler('foobar'); echo $str->length(); Regards, Thomas On Sat, Jan 26, 2013 at 11:45 AM, Pierre Joye <pierre.php@gmail.com> wrote: > hi, > > On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley <thbley+php@gmail.com> wrote: >> So function aliases, new open tag and deprecation are bad. What about >> the String class? >> I think there was some "Let's ... start exploring lighter and more >> approachable ways to attack Unicode" on internals ... > > Unicode is a totally different topic. I would suggest to look at intl > (ICU) extension for a start. > > Also about cleanup the APIs, take a look at this prototype: > > https://github.com/nikic/scalar_objects > > This is something that would be much cleaner and without BC problems. > > Cheers, > -- > Pierre > > @pierrejoye