Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Sat, 13 Dec 2003, Moriyoshi Koizumi wrote: > Overloading is evil, because functions like substr() are often > used to splice a certain length of octets byte-wise while mb_substr() > treats the sequence of octets on a character-basis. And overloading > cannot be turned on in scripts, this prevents us from writing portable > scripts. There're virtually no cleaner way to do the tasks elegantly. I also think overloading is evil, w've seen before what the problems can be because of difference between an overloaded and a non-overloaded version. It is however perfectly possible to tune this behavior in the php.ini file; not sure if we want that though. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Fri, 12 Dec 2003, Rasmus Lerdorf wrote: > We need to move towards a uniform platform that works for everyone without > putting undue strain on either side. Sure we do, but not at a 200-250% performance loss. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Fri, 12 Dec 2003, Ilia Alshanetsky wrote: > On December 12, 2003 08:54 pm, Moriyoshi Koizumi wrote: > > And overloading > > cannot be turned on in scripts, this prevents us from writing portable > > scripts. > > Not entirely true, while you cannot enable it from with a script you can > enable it for a particular directory via .htaccess or equivalent. Actually, this going to open a whole can of worms... I would call that a hack if it's done (though it might be a cool one :). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>: > > The cool thing that mbstring provides is transparent overloading of > > some > > of the common string manipulation functions. This means that at least > > for > > a subset of applications, even though they may not have been written > > with > > multibyte support in mind, they may in fact work perfectly in a > > multibyte > > environment with mbstring enabled and overloading turned on. > > Overloading is evil, because functions like substr() are often > used to splice a certain length of octets byte-wise while mb_substr() > treats the sequence of octets on a character-basis. And overloading > cannot be turned on in scripts, this prevents us from writing portable > scripts. There're virtually no cleaner way to do the tasks elegantly. I have to agree. While in the past it helped mb users to turn on overloading if they wanted to use our framework, it will now break it. This is because we now explicitely use the str*() function for byte-wise string manipulation and their mb_*() equivalents for character-wise manipulation. This is the only way to predict the results, the magic that is done by overloading or transparent charset conversion is not suitable for real production environments. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Derick Rethans <[EMAIL PROTECTED]>: > On Sat, 13 Dec 2003, Moriyoshi Koizumi wrote: > > > Overloading is evil, because functions like substr() are often > > used to splice a certain length of octets byte-wise while mb_substr() > > treats the sequence of octets on a character-basis. And overloading > > cannot be turned on in scripts, this prevents us from writing portable > > scripts. There're virtually no cleaner way to do the tasks elegantly. > > I also think overloading is evil, w've seen before what the problems can > be because of difference between an overloaded and a non-overloaded > version. It is however perfectly possible to tune this behavior in the > php.ini file; not sure if we want that though. I guess it depends on your pov. If you want to write portable scripts, relying on overloading or even special php.ini tuning is a nightmare. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] "Multiple Inheritance" for Interfaces
While porting PicoContainer to PHP 5 I noticed that we currently do not
support syntax to have an interface extend more than one parent
interface.
For instance
interface A {}
interface B {}
interface C extends A, B {}
is possible in Java while PHP 5 currently throws a syntax error, which
it does not for
interface A {}
interface B {}
interface C implements A, B {}
I have now two questions:
- Could we please add the syntax/semantic from Java so that interfaces
can extend more than one parent interface?
- Does
interface C implements A, B {}
do what I want?
Greetings,
Sebastian
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] "Multiple Inheritance" for Interfaces
Alle 16:09, sabato 13 dicembre 2003, Sebastian Bergmann ha scritto:
> - Does
>
> interface C implements A, B {}
>
> do what I want?
This syntax sounds strange to me: an interface should'nt _implement_
other interfaces... sounds as nonsense.
Ciao
ce
--
Cesare D'Amico - boss (@t) cesaredamico (dot) com
http://www.cesaredamico.com
To err is human, to forgive is not our policy.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] windows build system
Hi, for the new windows build system, what version of cscript.exe do I need (I seem to have 5.6 in C:\winnt\system32, which does not recognize /nologo as an option)? Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] "Multiple Inheritance" for Interfaces
Cesare D'Amico wrote:
Alle 16:09, sabato 13 dicembre 2003, Sebastian Bergmann ha scritto:
- Does
interface C implements A, B {}
do what I want?
This syntax sounds strange to me: an interface should'nt _implement_
other interfaces... sounds as nonsense.
That might be part of his point :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Sat, 13 Dec 2003, Jan Schneider wrote: > I have to agree. While in the past it helped mb users to turn on overloading > if they wanted to use our framework, it will now break it. This is because > we now explicitely use the str*() function for byte-wise string > manipulation and their mb_*() equivalents for character-wise manipulation. > This is the only way to predict the results, the magic that is done by > overloading or transparent charset conversion is not suitable for real > production environments. Using str*() functions for octet manipulation is fundamentally wrong. str*() functions by definition work on character boundaries. If we need to operate on byte boundaries we need to introduce a set of mem*() functions. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Destructors and Shutdown Sequence [OFF]
Hello Internals, I´m writing some material about PHP5 and I have some doubts about destructors. If someone would like to help me, it can be done in off. It´s basically how is the order that shutdown occurs in PHP5: - When exactaly __destruct() is called? - What resources still available at the time __destruct() is called? - What resources are not available anymore? I suppose it should be called before unload the extensions. But it wasnt happening (at least till some days ago). I´d like to illustrate how is the shutdown sequence, and show some examples of what can and what CAN´T be done. But I´m not so familiarized with the actual implementaton to find it by myself. Thanks for your attention. Eduardo R. Maciel __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Rasmus Lerdorf <[EMAIL PROTECTED]>: > On Sat, 13 Dec 2003, Jan Schneider wrote: > > I have to agree. While in the past it helped mb users to turn on > overloading > > if they wanted to use our framework, it will now break it. This is > because > > we now explicitely use the str*() function for byte-wise string > > manipulation and their mb_*() equivalents for character-wise > manipulation. > > This is the only way to predict the results, the magic that is done by > > overloading or transparent charset conversion is not suitable for real > > production environments. > > Using str*() functions for octet manipulation is fundamentally wrong. > str*() functions by definition work on character boundaries. If we need > to operate on byte boundaries we need to introduce a set of mem*() > functions. Maybe. Due to PHP lacking byte stream functions, working with str* is the only solution atm. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Sat, 13 Dec 2003, Jan Schneider wrote: > Maybe. Due to PHP lacking byte stream functions, working with str* is the > only solution atm. And my contention is that there is no way to do this right now. If you rely on a str*() function to do this your application is broken since you cannot reasonably expect a character to always be 8 bits wide. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/bz2 bz2.c /ext/curl streams.c /ext/standard file.c ftp_fopen_wrapper.c http_fopen_wrapper.c php_fopen_wrapper.c /ext/zlib zlib_fopen_wrapper.c /main php_streams.h /main/streams plain_wrapper.c streams.c userspace.c
Sara Golemon wrote: pollita Fri Dec 12 23:07:19 2003 EDT Modified files: /php-src/main php_streams.h /php-src/main/streams streams.c plain_wrapper.c userspace.c /php-src/ext/standard file.c ftp_fopen_wrapper.c http_fopen_wrapper.c php_fopen_wrapper.c /php-src/ext/zlib zlib_fopen_wrapper.c /php-src/ext/bz2bz2.c /php-src/ext/curl streams.c /php-srcNEWS Log: Route mkdir()/rmdir() via wrapper ops. Move current rmdir()/rmdir() code to plain_wrappers.c Implement mkdir()/rmdir() in ftp:// wrapper This broke the build for me on Windows: streams.c e:\home\php\php5\main\streams\streams.c(1471) : warning C4002: Zu viele übergebe ne Parameter für das Makro 'mkdir' e:\home\php\php5\main\streams\streams.c(1471) : error C2039: '_mkdir': Ist kein Element von '_php_stream_wrapper_ops' e:\home\php\php5\main\php_streams.h(133): Siehe Deklaration von '_php_st ream_wrapper_ops' e:\home\php\php5\main\streams\streams.c(1471) : warning C4033: '_php_stream_mkdi r' muss einen Wert zurückgeben e:\home\php\php5\main\streams\streams.c(1486) : warning C4002: Zu viele übergebe ne Parameter für das Makro 'rmdir' e:\home\php\php5\main\streams\streams.c(1486) : error C2039: '_rmdir': Ist kein Element von '_php_stream_wrapper_ops' e:\home\php\php5\main\php_streams.h(133): Siehe Deklaration von '_php_st ream_wrapper_ops' e:\home\php\php5\main\streams\streams.c(1486) : warning C4033: '_php_stream_rmdi r' muss einen Wert zurückgeben NMAKE : fatal error U1077: '"cl.exe"': R³ckgabe-Code '0x2' Stop. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Rasmus Lerdorf <[EMAIL PROTECTED]>: > On Sat, 13 Dec 2003, Jan Schneider wrote: > > Maybe. Due to PHP lacking byte stream functions, working with str* is > the > > only solution atm. > > And my contention is that there is no way to do this right now. If you > rely on a str*() function to do this your application is broken since you > cannot reasonably expect a character to always be 8 bits wide. With the current implemention and assuming that mbstring overloading is turned off, I can. This not documentated, but I'd still consider a change of this behaviour an huge bc break. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Sat, 13 Dec 2003, Jan Schneider wrote: > With the current implemention and assuming that mbstring overloading is > turned off, I can. This not documentated, but I'd still consider a change > of this behaviour an huge bc break. The documentation states "characters" and nowhere does it say the size of a character. I would not consider this a large BC break. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] With End With
On Thu, 2003-12-11 at 00:29, Alan Knowles wrote: > This has been discussed before on the mailing list, (either this or ZE2) > and rejected. - have a look through the archives http://zend.com/phorum/read.php?num=6&id=242&loc=0&thread=242 - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On 2003/12/14, at 1:07, Rasmus Lerdorf wrote: On Sat, 13 Dec 2003, Jan Schneider wrote: I have to agree. While in the past it helped mb users to turn on overloading if they wanted to use our framework, it will now break it. This is because we now explicitely use the str*() function for byte-wise string manipulation and their mb_*() equivalents for character-wise manipulation. This is the only way to predict the results, the magic that is done by overloading or transparent charset conversion is not suitable for real production environments. Using str*() functions for octet manipulation is fundamentally wrong. str*() functions by definition work on character boundaries. If we need to operate on byte boundaries we need to introduce a set of mem*() functions. I think single-byte users are prone to have a general assumption (indeed a superstition) that strlen() returns the number of octets and substr() cuts a portion of a string in a specified range of bytes, regardless of your conception of str*(). This sort of tendency applies to other programming languages. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/bz2 bz2.c /ext/curl streams.c /ext/standard file.c ftp_fopen_wrapper.c http_fopen_wrapper.c php_fopen_wrapper.c /ext/zlib zlib_fopen_wrapper.c /main php_streams.h /main/streams plain_wrapper.c streams.c userspac
I'm having to guess on the translation here, but it's sounding like it doesn't think mkdir is an element of php_stream_wrapper_ops. Although there seems to be a mention of mkdir/rmdir as macros in there? Perhaps renaming them to stream_mkdir/stream_rmdir will keep windows happy. Can you translate for me what these errors actually say? > This broke the build for me on Windows: > > streams.c > e:\home\php\php5\main\streams\streams.c(1471) : warning C4002: Zu viele > übergebe > ne Parameter für das Makro 'mkdir' > e:\home\php\php5\main\streams\streams.c(1471) : error C2039: '_mkdir': Ist > kein > Element von '_php_stream_wrapper_ops' > e:\home\php\php5\main\php_streams.h(133): Siehe Deklaration von > '_php_st > ream_wrapper_ops' > e:\home\php\php5\main\streams\streams.c(1471) : warning C4033: > '_php_stream_mkdi > r' muss einen Wert zurückgeben > e:\home\php\php5\main\streams\streams.c(1486) : warning C4002: Zu viele > übergebe > ne Parameter für das Makro 'rmdir' > e:\home\php\php5\main\streams\streams.c(1486) : error C2039: '_rmdir': Ist > kein > Element von '_php_stream_wrapper_ops' > e:\home\php\php5\main\php_streams.h(133): Siehe Deklaration von > '_php_st > ream_wrapper_ops' > e:\home\php\php5\main\streams\streams.c(1486) : warning C4033: > '_php_stream_rmdi > r' muss einen Wert zurückgeben > NMAKE : fatal error U1077: '"cl.exe"': R³ckgabe-Code '0x2' > Stop. > > -- > Sebastian Bergmann > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/bz2 bz2.c /ext/curl streams.c /ext/standard file.c ftp_fopen_wrapper.c http_fopen_wrapper.c php_fopen_wrapper.c /ext/zlib zlib_fopen_wrapper.c /main php_streams.h /main/streams plain_wrapper.c streams.c userspac
Nevermind, I forgot I could just look at the compile log on snaps. Looks like that's exactly the problem. I'll rename these methods to something less conflicting. -Sara "Sara Golemon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm having to guess on the translation here, but it's sounding like it > doesn't think mkdir is an element of php_stream_wrapper_ops. Although there > seems to be a mention of mkdir/rmdir as macros in there? Perhaps renaming > them to stream_mkdir/stream_rmdir will keep windows happy. > > Can you translate for me what these errors actually say? > > > This broke the build for me on Windows: > > > > streams.c > > e:\home\php\php5\main\streams\streams.c(1471) : warning C4002: Zu viele > > übergebe > > ne Parameter für das Makro 'mkdir' > > e:\home\php\php5\main\streams\streams.c(1471) : error C2039: '_mkdir': Ist > > kein > > Element von '_php_stream_wrapper_ops' > > e:\home\php\php5\main\php_streams.h(133): Siehe Deklaration von > > '_php_st > > ream_wrapper_ops' > > e:\home\php\php5\main\streams\streams.c(1471) : warning C4033: > > '_php_stream_mkdi > > r' muss einen Wert zurückgeben > > e:\home\php\php5\main\streams\streams.c(1486) : warning C4002: Zu viele > > übergebe > > ne Parameter für das Makro 'rmdir' > > e:\home\php\php5\main\streams\streams.c(1486) : error C2039: '_rmdir': Ist > > kein > > Element von '_php_stream_wrapper_ops' > > e:\home\php\php5\main\php_streams.h(133): Siehe Deklaration von > > '_php_st > > ream_wrapper_ops' > > e:\home\php\php5\main\streams\streams.c(1486) : warning C4033: > > '_php_stream_rmdi > > r' muss einen Wert zurückgeben > > NMAKE : fatal error U1077: '"cl.exe"': R³ckgabe-Code '0x2' > > Stop. > > > > -- > > Sebastian Bergmann > > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > > > Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /main php_streams.h /main/streams streams.c
Sara Golemon wrote: > pollita Sat Dec 13 13:48:40 2003 EDT > > Modified files: > /php-src/main php_streams.h > /php-src/main/streams streams.c > Log: > Fix Win32 Build. mkdir/rmdir are macros That fixed it, thanks, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] With End With
Timm Friebe wrote: On Thu, 2003-12-11 at 00:29, Alan Knowles wrote: This has been discussed before on the mailing list, (either this or ZE2) and rejected. - have a look through the archives http://zend.com/phorum/read.php?num=6&id=242&loc=0&thread=242 - Timm THanks for the thread, i see at least im not the only one that likes the idea, however, i would really prefer the syntax to seperate methods and properties from funcions and vars inside the with block. Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On 2003/12/13, at 9:36, Ilia Alshanetsky wrote: There is a good chance you are correct. However my assumption is not without bases, please consider the following statistic: Google finds 185,000 (or so) phpinfo() pages, when mbstring is added to the search query only 8150 pages are found. That leads me to believe that 1/2% of that userbase uses mbstring. Even if we were to say that of all the people who have mbstring compiled use it (which is highly unlikely) it's still only 1/2%. As a sidenote, this unrealistic statistics appear to be quite unreal. phpinfo() => 186,000 (pages) [1] phpinfo() mbstring => 8,330 phpinfo() Server API Configure Command => 16,800 phpinfo() Server API Configure Command mbstring => 4,510 [1] includes the number of pages that are not of actual phpinfo() and merely contain the keyword "phpinfo". Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On December 13, 2003 03:27 pm, Moriyoshi Koizumi wrote: > As a sidenote, this unrealistic statistics appear to be quite unreal. > > phpinfo() => 186,000 (pages) [1] > phpinfo() mbstring => 8,330 > phpinfo() Server API Configure Command => 16,800 > phpinfo() Server API Configure Command mbstring => 4,510 Even so this still represents a MINORITY. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On 2003/12/14, at 5:55, Ilia Alshanetsky wrote: On December 13, 2003 03:27 pm, Moriyoshi Koizumi wrote: As a sidenote, this unrealistic statistics appear to be quite unreal. phpinfo() => 186,000 (pages) [1] phpinfo() mbstring => 8,330 phpinfo() Server API Configure Command => 16,800 phpinfo() Server API Configure Command mbstring => 4,510 Even so this still represents a MINORITY. Could a quarter be a minority? And the fact is there are lots of people who don't know what is the problem when they've got to use multibyte strings. They don't realise why they should not use UTF-8 with their mysql server set to handle ISO-8859-1 for instance. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On December 13, 2003 03:53 pm, Moriyoshi Koizumi wrote: > Could a quarter be a minority? Unless the rules of mathematics had changed 25% is still a minority. You also forget that there are plenty of people who compile extensions and never end up using them. The critical point of this entire discussion is about NOT forcing choices on people who do not want/need them. There is no good reason to force multibyte version of fgetcsv() on every single user, when there are not one but two PHP extensions designed explicitly for multibyte support. If fgetcsv() in PHP 5 cannot be designed in such a way as to have no significant performance penalties for non-multibyte strings the function should be introduced as mb_fgetcsv() or iconv_fgetcsv(). Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On 2003/12/14, at 6:19, Ilia Alshanetsky wrote: On December 13, 2003 03:53 pm, Moriyoshi Koizumi wrote: Could a quarter be a minority? Unless the rules of mathematics had changed 25% is still a minority. You also forget that there are plenty of people who compile extensions and never end up using them. A similar fact applies to your assumption. It's also true that PHP can handle multibyte strings without mbstring or iconv in some cases where the users are just fortunate enough to not get in trouble, most likely because they just don't use such multibyte characters that are known to cause problems due to its structure. Those user question [1][2] exactly describes when it goes wrong. [1] http://marc.theaimsgroup.com/?l=php-dev&m=103828989330521&w=2 [2] http://news.php.net/article.php?group=php.i18n&article=633 The critical point of this entire discussion is about NOT forcing choices on people who do not want/need them. There is no good reason to force multibyte version of fgetcsv() on every single user, when there are not one but two PHP extensions designed explicitly for multibyte support. On the other hand, the chances are very limited to users familiar to multibyte. First of all, flexibility on the configuration has been causing lots of confusion. I'd be happy if every existing application used mb_*() instead of their counterpart at approproate places, but it's unlikely. This is because we have two versions of string manipulation functions. And again, it's prevented users to write multibyte safe applications because multibyte-flavor extensions are currently not enabled by default though this fact is not my point. If fgetcsv() in PHP 5 cannot be designed in such a way as to have no significant performance penalties for non-multibyte strings the function should be introduced as mb_fgetcsv() or iconv_fgetcsv(). So, why not begin thinking of how it could be bearably fast even with multibyte support enabled? While I think the current stuff I made is the best portable and the fastest code, it's probable that there are a far better code. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On 2003/12/14, at 6:46, Moriyoshi Koizumi wrote: I made is the best portable and the fastest code, it's probable that there are a far better code. s/there are/there'd be/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On December 13, 2003 04:46 pm, Moriyoshi Koizumi wrote: > > The critical point of this entire discussion is about NOT forcing > > choices on > > people who do not want/need them. There is no good reason to force > > multibyte > > version of fgetcsv() on every single user, when there are not one but > > two PHP > > extensions designed explicitly for multibyte support. > > On the other hand, the chances are very limited to users familiar > to multibyte. First of all, flexibility on the configuration has been > causing lots of confusion. I'd be happy if every existing application > used mb_*() instead of their counterpart at approproate places, but > it's unlikely. This is because we have two versions of string > manipulation > functions. And again, it's prevented users to write multibyte safe > applications because multibyte-flavor extensions are currently not > enabled > by default though this fact is not my point. Percentages aside you cannot deny the fact that not every application needs multibyte support (whether this is a majority or 50/50 does not matter). If a user needs to use multibyte they may need to do a little searching to find a provider that supports it, fortunately for them PHP is a very common scripting language with many hosting providers. > > If fgetcsv() in PHP 5 cannot be designed in such a way as to have no > > significant performance penalties for non-multibyte strings the > > function > > should be introduced as mb_fgetcsv() or iconv_fgetcsv(). > > So, why not begin thinking of how it could be bearably fast > even with multibyte support enabled? While I think the current stuff > I made is the best portable and the fastest code, it's probable > that there are a far better code. If your code as indeed as fast as it can be then the only alternative it would seem is to seperate the function into 'normal' and 'multibyte' variants allowing the user and not the developer to choose the one most suited to their needs. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ieure
I have been developing packages for PEAR, and I would like to keep them in a publicly accessible repository. Some of my PEAR work can be seen here: http://www.websprockets.com/~ieure/PEAR/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CVS Account Request: ieure
> From: Ian Eure [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 13, 2003 11:23 PM > I have been developing packages for PEAR, and I would like to keep them in > a publicly accessible repository. Err that is not quite how it works. Your code doesn't have to be finished to make it into PEAR CVS (after all CVS is for development). However before you can put it into PEAR CVS you need to go through the proposal voting system. See here for details: http://pear.php.net/manual/en/developers.contributing.php Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On 2003/12/14, at 7:33, Ilia Alshanetsky wrote: Percentages aside you cannot deny the fact that not every application needs multibyte support (whether this is a majority or 50/50 does not matter). If a user needs to use multibyte they may need to do a little searching to find a provider that supports it, fortunately for them PHP is a very common scripting language with many hosting providers. I haven't denied it. That said, multibyte facility is not so fancy as XML, but quite essential so as to enable most applications to work well under every environment. So, why not begin thinking of how it could be bearably fast even with multibyte support enabled? While I think the current stuff I made is the best portable and the fastest code, it's probable that there are a far better code. If your code as indeed as fast as it can be then the only alternative it would seem is to seperate the function into 'normal' and 'multibyte' variants allowing the user and not the developer to choose the one most suited to their needs. Let's stop doing such a stupid thing any more. As I pointed out already, having different versions for each function doesn't solve problems at all. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On December 13, 2003 05:52 pm, Moriyoshi Koizumi wrote: > I haven't denied it. That said, multibyte facility is not so fancy > as XML, but quite essential so as to enable most applications to work > well under every environment. Bullshit. Only application that need to support multibyte strings need the multibyte facility. > Let's stop doing such a stupid thing any more. As I pointed out already, > having different versions for each function doesn't solve problems at > all. It sure does, those who need to slower (multibyte) version use that and those who don't use the standard version which works nice and fast for non-multibyte strings. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] array_reverse
Hi there!
What you guys think about make array_reverse() a variable referenced
function. I mean something like:
function new_array_reverse(&$array){
$array = array_reverse($array);
}
Is it possible to make a function work both ways?
$array = array_reverse($array);
and
array_reverse($array);
I think that would be great!
Thanks in advance
Felipe Lopes.
_
Voce quer um iGMail protegido contra vírus e spams?
Clique aqui: http://www.igmailseguro.ig.com.br
Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tidy and B3
In response to the suggestions of Thies and others, I went back through
tidy and made a number of improvements to the API that I think should
make most people happy and make tidy ready for B3. Notable changes are:
Multiple Document Processing
$a = tidy_parse_file("http://www.php.net/";);
tidy_clean_repair($a);
echo tidy_get_output($a);
Dual-Nature Object and object overloading:
$a = tidy_parse_file("http://www.php.net/";);
$a->clean_repair();
echo $a;
echo $a->error_buf;
/* or... */
$a = new tidy_doc();
$a->clean_repair();
/* Of course, you can also cross-use the syntax */
$a = new tidy_doc();
tidy_clean_repair($a);
echo $a;
A bit cleaner parsing ability:
/* Get the Body node object */
$body = $a->body();
/* Get the 'BGCOLOR' attribute of the node */
echo $body->attribute['bgcolor'];
/* echo everything from */
echo $body;
/* Check to see if there is any content of the
body by looking for a child node. If there is,
echo only the content of the body... */
if($body->has_children()) {
echo $body->child[0]; /* Another node */
}
You can also specify a default tidy configuration setup by setting
tidy.default_config to a default configuration file, and automatically
have tidy clean/repair the output by setting tidy.clean_output to true.
I think with these changes tidy is ready to be packaged in B3, since no
one really opposed it before can we get this done ASAP? If you'd like to
play with tidy yourself, I have committed my work to HEAD in pecl/tidy
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
