> 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....@gmail.com> wrote:
> hi,
>
> On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley <thbley+...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
