Re: [PHP-DEV] Return type hints
Em, you have __call method in classes - via it you could implement ANY logic
for overloading. It's written in manual here:
http://www.php.net/manual/en/language.oop5.overloading.php
KISS should be followed - no C++ style overloading is needed, PHP is a
script language without strict type hinting.
2008/4/8, Krister Karlström [EMAIL PROTECTED]:
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen *
* Arcada - Nylands Svenska Yrkeshögskola *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699 GSM: +358(50)5328390 *
* E-mail: [EMAIL PROTECTED] *
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Yes it does, and not only for VB developers.
I'm plain PHP developer (with some small Pascal and Delphi background) and I
faced quite a lot situations when named parameters would give me a lot. In
stead had to write some nasty code like
myFunc($param1, $param2, array(), null, $paramX);
myFunc($param1, array(), $param4, $param5, $paramX);
And it wasn't a matter of placing function params in right order - I was
just impossible. Actual alternatives were in writing functions wrappers or
write specialized functions witch were doing the same taks, just didn't made
checks for params.
2008/4/8, Richard Quadling [EMAIL PROTECTED]:
On 08/04/2008, Arvids Godjuks [EMAIL PROTECTED] wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
I think Named Parameters would be nice for VB developers.
It makes a LOT of sense to have this I think.
Re: [PHP-DEV] Return type hints
Actually nothing could support my point about giving the wrong signals
better than these two postings: They are IMHO on the wrong track on how
to make an interface better.
Krister Karlström wrote:
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
sarcasm
Go back to Java please ;-)
/sarcasm
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
While I think named parameters are a good idea I pointed out in older
postings that I think this is a very crippled approach to it: You still
have to define all the parameters you are going to accept. The real
power and flexibility comes in if you accept (and handle) arbitrary
argument lists.
plug
See http://itools.search.ch/ for an example of what I mean.
/plug
Okay, enough evangelism for today, back to work :-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small test case fixes / observations (php-5.2.6_rc4)
On 2008-04-06 23:44, Christian Hoffmann wrote: Heya, while building and testing a minimal version of PHP and as such disabling the session extension, I discovered that ext/standard/tests/general_functions/bug44394_2.phpt fails without the session extension being enabled. I created a patch to fix that [1]. A similar problem: ext/pdo/tests/bug_43663.phpt and ext/pdo/tests/bug_44159.phpt rely on pdo_sqlite, but only check for pdo in their skipifs. Patch available [1]. [1] http://home.hoffie.info/static/006_test-pdo-bug_44159-43663-sqlite.patch -- Christian Hoffmann signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Return type hints
Yes indeed you can implement it using the __call method, but it would be
more readable if the language structure itself would support it. I
suggested this just because I think that this is the most common way of
using overloading, thus this probably would make sense to lot of users
out there.
But it was only a suggestion among others.
/Krister Karlström
Arvids Godjuks wrote:
Em, you have __call method in classes - via it you could implement ANY logic
for overloading. It's written in manual here:
http://www.php.net/manual/en/language.oop5.overloading.php
KISS should be followed - no C++ style overloading is needed, PHP is a
script language without strict type hinting.
2008/4/8, Krister Karlström [EMAIL PROTECTED]:
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases. Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen *
* Arcada - Nylands Svenska Yrkeshögskola *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699 GSM: +358(50)5328390 *
* E-mail: [EMAIL PROTECTED] *
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases. Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null, int $someint = 0){
}
myfunc($myArray, someint = $mySomeInt);
[PHP-DEV] Re: testfest
Ligaya Turmelle wrote: I wish to help with the testfest. Lukas told me to start asking some questions in here. So to help organize things I will add this information to the testfest wiki page and if you want pass on any changes for the testfest web page (or you can give me cvs access if you want). 1) Who is willing to be a mentor? What areas do you want to mentor? What areas are you willing to mentor? Where are you physically located if the local user group would like to work with you - what time frames would you be available? (feel free to respond off list to me with your info) I guess I'll mentor ;) I'm nearest to Chicago, but it's an almost three hour drive there. Time frames...errr... whenever. I'm busy but I can probably make time. I'm most comfortable with the edge stuff - and anything pertaining to windows (shmop, other little known extensions in core) and also PDO 2) How are UG's with no mentors locally available going to find a mentor? Should they contact someone personally that volunteers (info on the wiki or I don't mind being a connection point) or should they not worry about it and you (internals) will divvy up them up afterwards? Heck if I know 3) What areas does the group want to have people _really_ work on for the testfest (looked at gcov and am assuming anything in red - but anything in particular)? What areas would you prefer the people to work on (assuming yellow)? For beginners - what would you recommend people work on (core functionality)? Actually I think small extensions are a good place to start for beginners - it's actually harder to walk into a fairly well covered extension than it is to get base tests in place for an uncovered extension. I'd say shoot for the red, then yellow, than green ;) 4) I am assuming you would prefer to have people work on 5.3 for the testfest. Is that correct? Will there be a RC for the testfest or should people just use what is available from snaps? Heck if I know, I'd say either latest release or 5.3 snaps That should give me enough to get started. Any other info, ideas or suggestions would be appreciated. Have fun! Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
Hi Johannes,
Well, the idea is that all PHP-specific code is licensed under the same
license terms. PCRE and GD are external libraries which live outside
PHP's context and which are simply bundled. That's why the clear
preference there is PHP License.
I have updated the license to have it dual-licensed under PHP and BSD
licenses.
Additionally it would nice to follow the PHP coding standards. Like
always having { } after an if statement. This helps PHP developers who
might (possibly) help fixing reported (simple) bugs or apply API
changes.
The code has been updated to follow the PHP coding standards in regard
of using { }, if there is any other issue, please let me know, I will
fix it ASAP.
Other than that we, again, have our problem about what's the best way to
bundle something from pecl. I guess the symlink on the CVS server is
the best option we currently have...
Either a symlink or moving the directory physically to where other SAPI
code are should work. I can check in the code to a different location if
need.
Please let me know if anything I can help. :-)
Thanks,
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Scanner fixes and tweaks
Hi all,
First, I just realized while going through the scanner code after the re2c
changes that there's a bug with heredoc handling (from my code changes last
year, oops) on something like:
EOT
text
fooEOT
text
EOT;
Patch for 5.2 with just that fix:
http://realplain.com/php/heredoc_fix_5_2.diff
For 5.3 and HEAD, I fixed problems with yyleng (some would only affect
highlighting, tokenizer ext, etc.) Double quoted heredocs with tabs/spaces
wouldn't work right (ex:EOT). Updated some comments. And this
rule that was added...
ST_LOOKING_FOR_PROPERTY{WHITESPACE}+ {
/* do nothing */
goto restart;
}
Would lose that whitespace in highlighter, etc. or miss counting line
numbers. Speaking of line numbers, I also removed the
CG(comment_start_line) variable since I can't see that it's needed anywhere,
and CG(zend_lineno) works for the Unterminated comment... warning (which
isn't working right now anyway :-)).
In HEAD I also tidied up the LNUM/HNUM rules which lost their tabs and Z_*
macros a year ago (v1.164).
http://realplain.com/php/scanner_fixes.diff
http://realplain.com/php/scanner_fixes_5_3.diff
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Scanner fixes and tweaks
Thanks Matt,
I'll review these and merge them in with my other scanner fixes.
Scott
Matt Wilmas wrote:
Hi all,
First, I just realized while going through the scanner code after the re2c
changes that there's a bug with heredoc handling (from my code changes last
year, oops) on something like:
EOT
text
fooEOT
text
EOT;
Patch for 5.2 with just that fix:
http://realplain.com/php/heredoc_fix_5_2.diff
For 5.3 and HEAD, I fixed problems with yyleng (some would only affect
highlighting, tokenizer ext, etc.) Double quoted heredocs with tabs/spaces
wouldn't work right (ex:EOT). Updated some comments. And this
rule that was added...
ST_LOOKING_FOR_PROPERTY{WHITESPACE}+ {
/* do nothing */
goto restart;
}
Would lose that whitespace in highlighter, etc. or miss counting line
numbers. Speaking of line numbers, I also removed the
CG(comment_start_line) variable since I can't see that it's needed anywhere,
and CG(zend_lineno) works for the Unterminated comment... warning (which
isn't working right now anyway :-)).
In HEAD I also tidied up the LNUM/HNUM rules which lost their tabs and Z_*
macros a year ago (v1.164).
http://realplain.com/php/scanner_fixes.diff
http://realplain.com/php/scanner_fixes_5_3.diff
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Jeremy Privett wrote: Hi Scott, Scott MacVicar wrote: Can you try a debug build with --enable-debug to get a more detailed backtrace. Also what is the exact configure line and which apache 2 model are you using? Worker or Pre-fork? Scott On 29 Mar 2008, at 01:12, Jeremy Privett wrote: Hey list, I really /really/ hate to cause additional noise on this list, but I'm developing software in the PHP 5.3 snapshots with a timeline for release around the same time this version of PHP is released. We always try to keep current with our snapshots to make sure everything still works. My development team has been grinded almost to a halt by the fact that any thrown exception in the latest PHP 5.3 snapshots is causing Apache to crash. There's already a bug report here: http://bugs.php.net/bug.php?id=44226 I know unreleased PHP versions can't be supported, but fundamental language functionality was broken. This bug has been open for a month. This seems like it would be a critical problem and I'm glad Jani had already looked at and responded to the report. This is just slowing my team down when the snapshots are generally pretty high quality, from my personal experience. If this could be looked at further, I would gladly help someone with debugging and testing and such, if they'll take a look at the code. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. I mentioned it in my response to the bug report, but forgot to mention it here. I'm just using pre-built Windows Binaries for each. I'm on Windows XP Pro with SP2. Using Apache 2.2.8. Not sure what the exact Apache model is. Thanks for looking into this for me. Hey Scott and list, I wanted to check on this issue to see if anyone was actively working on it and see what I could do to help. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Hi! The ICU API solves this issue nicely using the current locale. It would be easier to work with the intl API if the same principle was used. Add a Locale::setDefault() and Locale::getDefault(). You can use default locale, of course, and Locale class already has these functions. http://docs.php.net/manual/en/class.locale.php The argument order for the constructors/factories should be change to allow that. The locale argument has to be optional (and moved as 2nd+ argument). I'm afraid that wouldn't work since functions have variable number of arguments and we want consistent API across all modules. Arguments order may be confusing and hard to remember. However their Like locale goes first? 4. Support of Date Object, they are the standard DateTime type in PHP. Planned to be done later - if anybody wants to contribute now, please do. It is indeed very important, we just don't have somebody to do it right now. 5. Error management is rather unintuitive. I can't imagine to have to check the error code after each call. Exceptions can greatly improve Like 99% people do with 99% functions in PHP? You must be really suffering not writing code in Java :) 6. What's about a __toString implementation when possible. It may be If you can propose good toString - and especially if you have volunteer to implement it :) - why not? We didn't have good use for toString, but if you find one - welcome. Prepare: $invoice_line_amount = new NumberFormatter( 'fr_CH', NumberFormatter::DECIMAL ); $invoice_line_amount-setValue($res); View: echo $invoice_line_amount; We didn't purport to implement yet another MVC templating system here. We wrote ICU wrapper. Locale specific: - Being able to parse, fetch and manage Locale IDs in a consistent and portable way would rock, the ISO3 related API is a must have prior 1.0. It can be used from day #1 to normalize locale IDs format. Could you elaborate? I think our functions understand locales in standard formats, but maybe you mean something else. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Hi Stan, On Tue, Apr 8, 2008 at 7:04 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: The ICU API solves this issue nicely using the current locale. It would be easier to work with the intl API if the same principle was used. Add a Locale::setDefault() and Locale::getDefault(). You can use default locale, of course, and Locale class already has these functions. http://docs.php.net/manual/en/class.locale.php I did not find a way to do it in the manual or in the code. How do I set in PHP? And how is it possible to use it as default for all further calls (no matter which class/method)? The argument order for the constructors/factories should be change to allow that. The locale argument has to be optional (and moved as 2nd+ argument). I'm afraid that wouldn't work since functions have variable number of arguments and we want consistent API across all modules. That's why I would prefer an array (as named arguments). The keys (names) are easy to remember. You can even support both. I'm ready to provide a patch to support array as input (with default values support) if we agree on that. Arguments order may be confusing and hard to remember. However their Like locale goes first? The locale as 1st argument always looked weird to me when I was writing my test code. The reason is certainly because of the default locale not being set or used. As it is possible (if I understand you correctly) I don't see why it has to be as first argument, one will always has to pass it (NULL/ or a valid locale id). 4. Support of Date Object, they are the standard DateTime type in PHP. Planned to be done later - if anybody wants to contribute now, please do. It is indeed very important, we just don't have somebody to do it right now. If right now is not within days but within 2 weeks, I can try to do it. But I first like to hear Derick's idea on the topic before. Please let us know your thoughts (wiki?) about this topic, it will certainly spare us some precious time. 5. Error management is rather unintuitive. I can't imagine to have to check the error code after each call. Exceptions can greatly improve Like 99% people do with 99% functions in PHP? You must be really suffering not writing code in Java :) Where did you get these numbers? For what I see nowadays, it is more a high percentage with OO for everything but some basic helpers. However, the point is not about OO or not OO but to do not duplicate the API without any gain. Locale::foo() is as easy to write or read than locale_foo(). 6. What's about a __toString implementation when possible. It may be If you can propose good toString - and especially if you have volunteer to implement it :) - why not? We didn't have good use for toString, but if you find one - welcome. I will think about it a bit more. But that will rock to have it :) Prepare: $invoice_line_amount = new NumberFormatter( 'fr_CH', NumberFormatter::DECIMAL ); $invoice_line_amount-setValue($res); View: echo $invoice_line_amount; We didn't purport to implement yet another MVC templating system here. We wrote ICU wrapper. I was not clear, sorry. The goal is not to create a MVC but to allow easy and user friendly usage without having to use intermediate string variable or other custom objects. Locale specific: - Being able to parse, fetch and manage Locale IDs in a consistent and portable way would rock, the ISO3 related API is a must have prior 1.0. It can be used from day #1 to normalize locale IDs format. Could you elaborate? I think our functions understand locales in standard formats, but maybe you mean something else. The idea is to have a way to get a code for a language, or to valid a given code, etc. Many applications actually duplicate this list internally, it would be very nice to be able to deal with the ICU lists (display, validation, listings, etc.). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Hi! I did not find a way to do it in the manual or in the code. How do I set in PHP? And how is it possible to use it as default for all further calls (no matter which class/method)? Locale::setDefault() and Locale::DEFAULT. That's why I would prefer an array (as named arguments). The keys We aimed to create a wrapper for ICU, not reinvent how PHP language works. So we accept arguments the usual way - through function parameters, not through arrays. The locale as 1st argument always looked weird to me when I was writing my test code. The reason is certainly because of the default I guess that's a matter of personal taste. If right now is not within days but within 2 weeks, I can try to do it. But I first like to hear Derick's idea on the topic before. Please let us know your thoughts (wiki?) about this topic, it will certainly spare us some precious time. Well, the thoughts here are pretty simple - where date formatting functions accept timestamp and localtime array, they should accept DateTime object too. Also, there should be parse function returning DateTime, like one that returns timestamp. I think if you look in CVS in doc folder, early versions of date formatter API mention that. The idea is to have a way to get a code for a language, or to valid a given code, etc. Many applications actually duplicate this list internally, it would be very nice to be able to deal with the ICU lists (display, validation, listings, etc.). You mean create API translating from language name in given locale to language code? I'm not sure ICU has this API. Locale class allows you to get components and display strings for the locales, but you have to have locale IDs first. There also are some matching functions in Locale, but I don't see any ICU functions allowing you to know IDs from external information, only to choose from set of IDs and enquire about ID. As for validity, since locale mechanism has a bunch of fallbacks, I understand the validity concept is a bit blurred. I.e. you can have regexp to check all the -'s or _'s are in place but beyond that it's kind of hard to know what the question is en_RU locale valid? means. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Hi! On Tue, Apr 8, 2008 at 8:53 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I did not find a way to do it in the manual or in the code. How do I set in PHP? And how is it possible to use it as default for all further calls (no matter which class/method)? Locale::setDefault() and Locale::DEFAULT. Damned, I missed it four times :) It is not present in the synopsis but in the methods list. Then I really don't understand the current methods signature. The locale should be optional and obivously not as first argument. That's why I would prefer an array (as named arguments). The keys We aimed to create a wrapper for ICU, not reinvent how PHP language works. So we accept arguments the usual way - through function parameters, not through arrays. You may aim to create a thin wrapper around ICU, but we aim to create the best possible i18n API. :-) There is many API using this method when there is too many arguments, when the risk of confusions is high. About creating a wrapper, that's actually part of the solution to do not create a thin wrapper but to add some intelligence in the extension to ease its usage. It is even more important for APIs like what intl try to do as it will be used by almost everyone out there. The locale as 1st argument always looked weird to me when I was writing my test code. The reason is certainly because of the default I guess that's a matter of personal taste. No, that's a matter of being able to use a default locale without passing NULL or an empty string. That's really bad practice to have an optional argument as first argument. If right now is not within days but within 2 weeks, I can try to do it. But I first like to hear Derick's idea on the topic before. Please let us know your thoughts (wiki?) about this topic, it will certainly spare us some precious time. Well, the thoughts here are pretty simple - where date formatting functions accept timestamp and localtime array, they should accept DateTime object too. Also, there should be parse function returning DateTime, like one that returns timestamp. I think if you look in CVS in doc folder, early versions of date formatter API mention that. Thanks for the hint, I will take a look at the history. The idea is to have a way to get a code for a language, or to valid a given code, etc. Many applications actually duplicate this list internally, it would be very nice to be able to deal with the ICU lists (display, validation, listings, etc.). You mean create API translating from language name in given locale to language code? I'm not sure ICU has this API. Locale class allows you to get components and display strings for the locales, but you have to have locale IDs first. There also are some matching functions in Locale, but I don't see any ICU functions allowing you to know IDs from external information, only to choose from set of IDs and enquire about ID. As for validity, since locale mechanism has a bunch of fallbacks, I understand the validity concept is a bit blurred. I.e. you can have regexp to check all the -'s or _'s are in place but beyond that it's kind of hard to know what the question is en_RU locale valid? means. It is amazingly handy to know that a locale given by the user (UI or a developer using your library) is valid. What I like to have are getCountry, getISO3* etc. I can provide a list and then a patch. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
As for validity, since locale mechanism has a bunch of fallbacks, I understand the validity concept is a bit blurred. I.e. you can have regexp to check all the -'s or _'s are in place but beyond that it's kind of hard to know what the question is en_RU locale valid? means. It is amazingly handy to know that a locale given by the user (UI or a developer using your library) is valid. What I like to have are getCountry, getISO3* etc. I can provide a list and then a patch. I think locale validity detection does not work in PHP6 locale_set_default() too. Bug 42471. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: kwilms
I have a PEAR package Crypt_MicroID (http://pear.php.net/pepr/pepr-proposal-show.php?id=542) that has been approved. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
re, On Tue, Apr 8, 2008 at 9:35 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: It is amazingly handy to know that a locale given by the user (UI or a developer using your library) is valid. What I like to have are What is valid? Database can have no exact match for locale string, but still have some data from fallbacks, etc. getCountry, getISO3* etc. I can provide a list and then a patch. You have getRegion, but it looks like no ISO ones now. The current one is somehow limited given what ICU provides. I know that locale string are evil but it is the exact reason why we should help our developers to use some more standard one, whenever it is possible. Having the previously cited functions as well as getISO*, getAvailableLocale, etc. will help. Will you agree to extend the Locale API to provide more informations? -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Hi! It is amazingly handy to know that a locale given by the user (UI or a developer using your library) is valid. What I like to have are What is valid? Database can have no exact match for locale string, but still have some data from fallbacks, etc. getCountry, getISO3* etc. I can provide a list and then a patch. You have getRegion, but it looks like no ISO ones now. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Hi! Will you agree to extend the Locale API to provide more informations? If it makes sense and consistent with what ICU has - sure. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: mimmi
Thomas Mueller wrote: distributing a new package Which package? For what? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Off the top of my head, ICU has this path style syntax to query CLDR
data. I think that would be pretty important - the data is there, and
grabbing it shouldn't be too difficult (can't check right now, but
it's something like $locale-getInfo('currencyNames/EUR/long') or
whatever).
I also agree on the DateTime thing, and I, too, wonder why we need a
procedural API for this - especially since it makes error handling so
much easier (exceptions everywhere and done).
David
Am 08.04.2008 um 22:04 schrieb Stanislav Malyshev:
Hi!
Will you agree to extend the Locale API to provide more informations?
If it makes sense and consistent with what ICU has - sure.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Am 08.04.2008 um 21:09 schrieb Pierre Joye: The idea is to have a way to get a code for a language, or to valid a given code, etc. Many applications actually duplicate this list internally, it would be very nice to be able to deal with the ICU lists (display, validation, listings, etc.). You mean create API translating from language name in given locale to language code? I'm not sure ICU has this API. Locale class allows you to get components and display strings for the locales, but you have to have locale IDs first. There also are some matching functions in Locale, but I don't see any ICU functions allowing you to know IDs from external information, only to choose from set of IDs and enquire about ID. As for validity, since locale mechanism has a bunch of fallbacks, I understand the validity concept is a bit blurred. I.e. you can have regexp to check all the -'s or _'s are in place but beyond that it's kind of hard to know what the question is en_RU locale valid? means. It is amazingly handy to know that a locale given by the user (UI or a developer using your library) is valid. What I like to have are getCountry, getISO3* etc. I can provide a list and then a patch. Note that most of this info is already in the CLDR info. And I am with Stas here, not sure if it's really necessary. You can do this mapping by hand, if necessary, but trust me, it isn't in most cases; you know the locale IDs beforehand. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
I also agree on the DateTime thing, and I, too, wonder why we need a procedural API for this - especially since it makes error handling so much easier (exceptions everywhere and done). Sure. If you happen to be one of the few PHP users who puts everything into try/catch blocks as a matter of course. Wearing my 'editor/educator' hat, can I just point out that we're still teaching long-time PHP users from all over the planet what exceptions even are? Can I also point out that *every* uncaught exception is a fatal error? This isn't how PHP used to be. This is a whole new way of coding, and you'd like to force it onto people who never did that CS degree, but who coped just fine until now. How sweet. So please, yes, keep the procedural way as an option, make it possible for people to use PHP without their having to be computer scientists first. The moment the language loses that, it has nothing special to offer any more. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Steph Fox wrote: So please, yes, keep the procedural way as an option, make it possible for people to use PHP without their having to be computer scientists first. The moment the language loses that, it has nothing special to offer any more. +1 Nothing beats procedural for the quick and dirty prototype. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] practical phar considerations
Lars Strojny wrote:
Hi Greg,
Am Samstag, den 29.03.2008, 17:58 -0500 schrieb Greg Beaver:
[...]
If one uses file_put_contents('/path/to/this/file', 'hi') and
'/path/to/this' does not exist, there is an error. The same is true of
fopen, regardless of mode. mkdir() even fails unless the recursive
parameter is explicitly specified. I do not think that this behavior
should be different in ext/phar, especially because all that is needed
is to create 1 directory (full/path/to/) and add the file.
I mostly agree. Except that the whole argument chain applies to the
current API. You mentioned mkdir(foo/bar/baz) triggering an error
without the recursive argument, but Phar['foo/bar/baz'] does not.
[... Performance concerns ...]
$phar['long/path/to/subdir/file'] = 'hi';
compared to:
$phar['long']['path']['to']['subdir']['file'] = 'hi';
is significantly slower. Each [] results in a call to offsetGet and
instantiation of a new PharFileInfo object plus the final offsetSet call.
Could you estimate how hard that performance hit would be?
We're talking about a similar difference between iterating over an array
and using an ArrayIterator, which is to say about 20 times slower. This
is due to the many extra opcodes for each offset retrieval, which then
calls an expensive method call to offsetGet(), creates the directory
inside the phar archive, writes to disk, and continues. Because we are
writing to disk, without a not-at-all-obvious startBuffering() call,
with large archives, the performance difference could be 100 times
slower or more.
In addition, although Phar does support the idea of thinking of archives
as multi-dimensional arrays, this is an abstraction not supported by the
actual archive file formats. For other examples, take a look at at
ext/zip. There is no support for opendir() in the stream wrapper of
ext/zip because it requires the kind of path grepping that pecl/phar
does. Internally, no archive format stores paths the way directories
are stored in a typical file system. In other words, typically a
directory is a file that contains a list of other files or directories.
This allows very quick navigation on a random access disk, but causes
extreme bloat inside an archive. Files are stored as full paths in what
is the equivalent of a single-dimensional array. In other words, the
truth of the matter is that phar's ArrayAccess API is a 100% accurate
reflection of the true structure of the actual archives we are
accessing, and the iteration supported is a convenience for simulating
regular file systems. The API you describe actually layers an
artificial complexity over this design, and as a result requires much
more code complexity.
Let's also remember we're talking about phar creation, which is going to
be far less common than phar usage. To use a phar, you don't even need
to know what phar *is* let alone what the API is. One just includes the
phar archive, or adds it to include_path with a phar:// stream wrapper path.
I've spent a significant amount of time actually implementing the new
read-only implementation of offsetGet() in the past day, and although I
think this might be possible I am running into a weird segfault in SPL
on shutdown caused by a double destruction of the object. In addition,
the patch is not even close to complete, as it does not support the
addition of ArrayAccess to PharFileInfo, which would be required in
order to implement what your RFC describes. The complexity of the patch
is reaching the hundreds of lines and will be in the thousands of lines,
all to add syntactic sugar that is far more inefficient than the current
syntax - is this really a necessary feature?
As Elizabeth points out, most people are going to build their iterator
by creating a directory structure and then add the entire directory all
at once. Use of ArrayAccess to write to the archive would be done for
one or two files at most.
When reading from a phar, there is no real incentive to use relative
paths outside of scanning a directory for files (to locate drivers or
plugins, for instance), and iterating over the entire archive is usually
reserved for searching for a particular file. The ability to glob
through a phar archive would of course be the most ideal solution for
that approach (perhaps globiterator already works? I haven't tried it).
What I would like to do, however, is to rethink offsetSet(). I think
that we should introduce a property of PharFileInfo called content
that is read/write, and can be used to perform the equivalent of
file_get_contents()/file_put_contents(). This will allow a consistency
that is much more intuitive. offsetSet() could then simply be removed,
or perhaps be refactored as a way to pass in a PharFileInfo and clone
the information.
Yes, this shouldn't be allowed while
$phar['foo/bar/baz'] = new DirectoryIterator(); could be allowed.
I will simply add makeEmptyDir() a la zip, although it is too bad
ext/zip never thought to
