Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension [RSS Feed]

#1 March 26, 2008 21:02:56

Stanislav M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension


Hi!As intl will requires it, why is it unacceptable?intl is specialized extension for people dealing with globalenvironments. It will be enabled only by people that really need it.ext/date is much more general-purpose function, used by thousands ofapplications that don't care at all about global calendars and other ICUstuff. Requiring them to have ICU library and carry it around justbecause they want dates, and because of the possibility that somedaysomeone might want to print dates both in French and Russian does notseem like a smart move to me.If you think (you as in all of you :) that having ICU as required
dependency in 5.3 is not acceptable, we can make it optional. ThatHow? If date formatter built into ext/date, ext/date in order to buildwould require ICU.would be bad for intl as we will not be able to rely on it. About 5.2,
there is no clean solution but to provide the same API than the one
available through ext/date but via pecl/intl (that does not sound too
complicated and would solve the forward compatibility problem).I'm not sure what you are proposing here, could you explain?Just in case it is relevant, I do not think it is practical to splitcode bases between 5.2 and 5.3 - unless somebody volunteers to supportthese separate branches - maintaining 5 and 6 separately is work enough.If it's irrelevant, please ignore it.--
Stanislav Malyshev, Zend Software Architect
http://www.zend.com/(408)253-8829 MSN:

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 March 26, 2008 21:22:36

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension


Hi,

On Wed, Mar 26, 2008 at 9:02 PM, Stanislav Malyshev <> wrote:
> Hi!
>
>
> > As intl will requires it, why is it unacceptable?
>
> intl is specialized extension for people dealing with global
> environments. It will be enabled only by people that really need it.
> ext/date is much more general-purpose function, used by thousands of
> applications that don't care at all about global calendars and other ICU
> stuff. Requiring them to have ICU library and carry it around just
> because they want dates, and because of the possibility that someday
> someone might want to print dates both in French and Russian does not
> seem like a smart move to me.
>
>
> > If you think (you as in all of you :) that having ICU as required
> > dependency in 5.3 is not acceptable, we can make it optional. That
>
> How? If date formatter built into ext/date, ext/date in order to build
> would require ICU.

This feature can then be optional in ext/date. That should not be an
issue for those not willing to use a reliable date formatting system
as they are certainly not interested in intl either.

> > would be bad for intl as we will not be able to rely on it. About 5.2,
> > there is no clean solution but to provide the same API than the one
> > available through ext/date but via pecl/intl (that does not sound too
> > complicated and would solve the forward compatibility problem).
>
> I'm not sure what you are proposing here, could you explain?
>
> Just in case it is relevant, I do not think it is practical to split
> code bases between 5.2 and 5.3 - unless somebody volunteers to support
> these separate branches - maintaining 5 and 6 separately is work enough.
> If it's irrelevant, please ignore it.

You can't add code in 5.2 but you can add everything feature you wish
in pecl/intl. The only extra work is an extra commit for the date
related code in pecl/intl. That's not that much work (I do that for
zip and gd). It will also be required if you like to continue to
release intl through PECL once it is bundled (you have to do it
anyway, for the 5.2 users). Also, please note that this
synchronization job can be done once at release time, not on each
commit.

That's the only clean solution I can think about if you like to have
the date formatter available for 5.2 users. But I will rather drop it
for 5.2 if it is a show stopper to do it in ext/date in 5.3+.

Cheers,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 March 26, 2008 21:38:46

Stanislav M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension


Hi!This feature can then be optional in ext/date. That should not be an
issue for those not willing to use a reliable date formatting system
as they are certainly not interested in intl either.I think making it optional in ext/date would be harder. On top of that,optional functions in existing classes aren't really easy to work with -they are hard to check for, it would be harder to explain people how toenable it if missing, and it will definitely be harder to maintain.I think much better solution is to make it separate entity in PHP 5 andintegrated in PHP 6 (in PHP 6 we are going to integrate some parts onintl anyway - locale, probably collator too, and we already have ICU).You can't add code in 5.2 but you can add everything feature you wish
in pecl/intl. The only extra work is an extra commit for the dateDo I understand it right that you propose copying code from intl toext/date? If so, I think it would be counterproductive - the code is awell-encapsulated module, which can exist on its own, it will requirerewriting (including probably importing a set of utility functions) forputting it into ext/date and will not provide additional function butonly code duplication.If I misunderstood your proposal, please explain further.That's the only clean solution I can think about if you like to have
the date formatter available for 5.2 users. But I will rather drop it
for 5.2 if it is a show stopper to do it in ext/date in 5.3+.We do not want to drop date formatter, especially since it is a workingcode that provides function required by people. As far as I can see, italso does not cause any problem or any conflict with anything, andintegrating it with ext/date functionally can easily be done while it isseparate from ext/date code-wise. Actually, it was initially planned -i.e. having formatter to accept/create objects produced by ext/date -but we didn't have resources to make it happen for now. If we wrap itnow for 1.0 release, we still can do it for 1.1.--
Stanislav Malyshev, Zend Software Architect
http://www.zend.com/(408)253-8829 MSN:

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 March 26, 2008 21:55:21

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension


On Wed, Mar 26, 2008 at 9:38 PM, Stanislav Malyshev <> wrote:
> Hi!
>
>
> > This feature can then be optional in ext/date. That should not be an
> > issue for those not willing to use a reliable date formatting system
> > as they are certainly not interested in intl either.
>
> I think making it optional in ext/date would be harder. On top of that,
> optional functions in existing classes aren't really easy to work with -
> they are hard to check for, it would be harder to explain people how to
> enable it if missing, and it will definitely be harder to maintain.

I meant to make the DateFormatter class not available when ICU is not available.

> > You can't add code in 5.2 but you can add everything feature you wish
> > in pecl/intl. The only extra work is an extra commit for the date
>
> Do I understand it right that you propose copying code from intl to
> ext/date?

I meant to duplicate the code from ext/date (where it belongs) in
pecl/intl. Please notice the "pecl/intl" not php-src/ext. The goal is
to provide the DateFormatter feature to php 5.2 users.

> If so, I think it would be counterproductive - the code is a
> well-encapsulated module, which can exist on its own, it will require
> rewriting (including probably importing a set of utility functions) for
> putting it into ext/date and will not provide additional function but
> only code duplication.

As Derick said, it should be in ext/date. I quickly reviewed the
dateformat/* code and did not catch any stopping point to actually
move the code in ext/date. I agree that it will add some tiny extra
work but it is really worth the effort. Having the date code in one
place will benefit the users, from a quality and usability point of
view.


> > That's the only clean solution I can think about if you like to have
> > the date formatter available for 5.2 users. But I will rather drop it
> > for 5.2 if it is a show stopper to do it in ext/date in 5.3+.
>
> We do not want to drop date formatter, especially since it is a working
> code that provides function required by people. As far as I can see, it
> also does not cause any problem or any conflict with anything, and
> integrating it with ext/date functionally can easily be done while it is
> separate from ext/date code-wise. Actually, it was initially planned -
> i.e. having formatter to accept/create objects produced by ext/date -
> but we didn't have resources to make it happen for now. If we wrap it
> now for 1.0 release, we still can do it for 1.1.

That could work as well as long as it is:

- completely transparent to the users (no worry here)
- team work and (very) good communication between ext/date
maintainers and intl maintainers (I worry more here ;), that means
ext/date maintainers should have a word/voice in intl :)

Cheers,
--
Pierrehttp://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 March 26, 2008 22:02:42

Stanislav M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension


Hi!I meant to duplicate the code from ext/date (where it belongs) in
pecl/intl. Please notice the "pecl/intl" not php-src/ext. The goal is
to provide the DateFormatter feature to php 5.2 users.Great, right now 5.2 users can use intl extension from pecl, includingDateFormatter.As Derick said, it should be in ext/date. I quickly reviewed the
dateformat/* code and did not catch any stopping point to actually
move the code in ext/date. I agree that it will add some tiny extraYou'll also need to copy error handling and charset conversion, at least.work but it is really worth the effort. Having the date code in one
place will benefit the users, from a quality and usability point of
view.Actually, the users couldn't care less in which directory the sourcecode was located. They care about the API provided - so do you proposeto provide different API? If so, which one?As for quality, I don't see what extra quality would copying this codeprovide.That could work as well as long as it is:

- completely transparent to the users (no worry here)
- team work and (very) good communication between ext/date
maintainers and intl maintainers (I worry more here ;), that means
ext/date maintainers should have a word/voice in intl :)As I already said, anybody who wants to contribute is welcome. Actually,only discussion on date (or any non-bug-related matters for that matter:) is held for now right here. If you want to move it, say, to php-i18n,I'm OK with that too.--
Stanislav Malyshev, Zend Software Architect
http://www.zend.com/(408)253-8829 MSN:

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 March 27, 2008 09:26:07

Lester C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension


Stanislav Malyshev wrote:Hi!I meant to duplicate the code from ext/date (where it belongs) in
pecl/intl. Please notice the "pecl/intl" not php-src/ext. The goal is
to provide the DateFormatter feature to php 5.2 users.Great, right now 5.2 users can use intl extension from pecl, includingDateFormatter.As Derick said, it should be in ext/date. I quickly reviewed the
dateformat/* code and did not catch any stopping point to actually
move the code in ext/date. I agree that it will add some tiny extraYou'll also need to copy error handling and charset conversion, at least.work but it is really worth the effort. Having the date code in one
place will benefit the users, from a quality and usability point of
view.Actually, the users couldn't care less in which directory the sourcecode was located. They care about the API provided - so do you proposeto provide different API? If so, which one?As for quality, I don't see what extra quality would copying this codeprovide.That could work as well as long as it is:

- completely transparent to the users (no worry here)
- team work and (very) good communication between ext/date
maintainers and intl maintainers (I worry more here ;), that means
ext/date maintainers should have a word/voice in intl :)As I already said, anybody who wants to contribute is welcome. Actually,only discussion on date (or any non-bug-related matters for that matter:) is held for now right here. If you want to move it, say, to php-i18n,I'm OK with that too.Personally I see this as another totally irrelevant side track from gettingPHP6 out!*I* have a perfectly functional date system that I have no intention ofchanging until I *CAN* go to a stable unicode based system. Blasting 'Date'into earlier versions broke that for many of us without actually offeringanything practical and as yet I see no reason to waste time changing !!!PLEASE can all this effort on YET ANOTHER VERSION OF PHP (5.3) be directed togetting a stable build of PHP6 out of the door so we can all have something toaim for. Changing and extending PHP5 yet again is distracting from getting allthe PHP4 users on board, so can we please nail PHP5 down NOW and keep all thispotentially nice stuff until we HAVE a new flat platform.I can see peoples arguments for not standardising on unicode but nowadays withinternational trade ALL of my web site activity HAS to cope with names andaddresses from around the world so even ascii luddites will get caught outsometime unless they have found a way to block all overseas access :(--
Lester Caine - G8HFL
-----------------------------
Contact -http://home.lsces.co.uk/lsces/wiki/?page=contactL.S.Caine Electronic Services -http://home.lsces.co.ukEnquirySolve -http://enquirysolve.com/Model Engineers Digital Workshop -http://medw.co.uk//Firebird -http://www.firebirdsql.org/index.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension [RSS Feed]

Board footer

Moderator control

Enjoy the 11th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support