Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
On Fri, 2003-12-12 at 23:28, Ilia Alshanetsky wrote: > On December 12, 2003 04:18 pm, Moriyoshi Koizumi wrote: > > I disagree, because of the following reasons: > > > > 1) Not a few people *actually* use fgetcsv() commonly > > with multibyte characters indeed. Regarding this, > > applications made by those who don't use > > such characters don't (and won't) use multibyte specific > > functions and that's the problem. This greatly prevents > > them from being portable. > > People have lived without multibyte support in fgetcsv() for many years now, > and I did not see a single request on bugs.php.net for fgetcsv() multi-byte > support. So, while this is certainly useful functionality I do not believe it > is as widely needed as you say it is. We also have a multibyte extension that > already implements multi-byte safe variants of common functions, why make > exception for fgetcsv() and add multibyte code into core? Just an observation: it seems that the PHP users who need multibyte support are generally self-supplied by default. It's often hard to convince programmers to change their code as fundamentally as you often need to do to support not just UTF-8 but the whole range of CJK charsets, it adds complexity and can slow things down. These users are used to maintaining their own patches for all kinds of software. The process of merging in multibyte character features often takes several years. Because of this (if my observation is correct), you can't really tell for example how many Japanese users are having issues with fgetcsv() by counting requests on bugs.php.net. I agree with Moriyoshi Koizumi that performance is not necessarily the primary factor here. IMHO performance is important, but generality and realibility is more so. With all due respect to everyone, I think that we should be a bit more welcoming to people who offer help in making PHP a better language for CJK websites. There's still a huge amount of marketshare waiting for PHP in Asia. :-) - Stig -- 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 Sun, 2003-12-14 at 00:28, Ilia Alshanetsky wrote: > 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. So you think the right solution is to dismiss multibyte users and direct them to the hacks (mbstring etc) that have been used previously instead of thinking ahead? If I were starting a language from scratch today, I would make character encoding part of the string "zval" structure. IMHO that's where it belongs. As an alternative for PHP 5[.1], there is room for a "multibyte bit" in the zval that various functions can use to choose between "sizeof(byte)==sizeof(char)" and "sizeof(byte) < sizeof(char)" implementations. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: glpmello
Control version -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
Guys, We have had this discussion before. There are two extremes to this issue. The first is to always require the explicit __toString() call and the second is to never require it and have all places in PHP whether it's str_replace(), (string)$obj, $arr[$obj] to automatically convert to string. The latter is problematic because it propagates to far too many places and causes too much magic in my opinion. I think the right trade off is to automatically convert it with "print" and with concatenation. All the rest will require explicit calling. It might not be your dream but it's a realistic approach. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
Hi Andi, On Mon, Dec 15, 2003 at 02:28:41PM +0200, Andi Gutmans wrote : > We have had this discussion before. There are two extremes to this issue. > The first is to always require the explicit __toString() call and the > second is to never require it and have all places in PHP whether it's > str_replace(), (string)$obj, $arr[$obj] to automatically convert to string. > The latter is problematic because it propagates to far too many places and > causes too much magic in my opinion. > I think the right trade off is to automatically convert it with "print" and > with concatenation. All the rest will require explicit calling. > It might not be your dream but it's a realistic approach. I understand your concern about too much magic very well. But, isn't it the fact the only people who "know what they're doing" will start to take advantage of __toString ? I cannot imagine that beginners will start to implement their own __toString methods right from the start. Doesn't this limit the number of people who might shoot themselves by a great deal? So, to take advantage that any object has the string-autocast feature one needs to implement __toString. But by the time people do this, they know how it works (else why should the use __toString if they wouldn't know about its advantage [letting alone those poor people naming their methods accidantly __toString]). The option to call __toString on concatenation also will probably result in such code return $someobject . ""; instead of return $someobject->__toString(); - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
On Mon, 15 Dec 2003, Andi Gutmans wrote: > I think the right trade off is to automatically convert it with "print" and > with concatenation. All the rest will require explicit calling. > It might not be your dream but it's a realistic approach. Why print and no echo? ;-) (Or was it the same again...) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
Andi Gutmans wrote: > I think the right trade off is to automatically convert it with "print" > and with concatenation. I can live with that and my only concern was whether or not the above feature was removed or broken. -- 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] __toString()
Derick Rethans wrote: Why print and no echo? ;-) (Or was it the same again...) I hope print and echo will be treated the same. It looks like right now __toString() is never called automatically, I just updated from CVS and I get "Object id #1" for the example program. BTW: The example in Zend/ZEND_CHANGES is outdated: Example: $obj = Foo; ^^^ should be "new Foo" $str = (string) $obj; // call __toString() ^^^ This line should be removed I guess echo $obj; // call __toString() ^^^ should mention print too I guess ?> Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
If you are going to create an interface, the most
reasonable way of implementing that, is by not doing
so much magic, and only permit the cast explicitly
using (string)$obj for objects that implements the
interface Stringable.
So problems like:
return $someobject . "";
could be solved by using:
return (string)$someobject;
The same reflects on Jon´s example:
function printException($e)
{
if (is_object($e) && method_exists($e,
'__toString')) {
print $e->__toString();
} else {
print $e;
}
}
could just be:
function printException($e)
{
print (string)$e;
}
Marc.
__
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)
On December 15, 2003 05:37 am, Stig S. Bakken wrote: > So you think the right solution is to dismiss multibyte users and direct > them to the hacks (mbstring etc) that have been used previously instead > of thinking ahead? IMHO calling multibyte a hack would be great disservice to the developers of that extension. We don't call ext/pgsql a hack, simply because it's not builtin, do we? > If I were starting a language from scratch today, I would make character > encoding part of the string "zval" structure. IMHO that's where it > belongs. As an alternative for PHP 5[.1], there is room for a > "multibyte bit" in the zval that various functions can use to choose > between "sizeof(byte)==sizeof(char)" and "sizeof(byte) < sizeof(char)" > implementations. If you were designing a new language you wouldn't have legacy users who'd suffer (significantly) because of features added for other users. 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/16, at 0:32, Ilia Alshanetsky wrote: On December 15, 2003 05:37 am, Stig S. Bakken wrote: So you think the right solution is to dismiss multibyte users and direct them to the hacks (mbstring etc) that have been used previously instead of thinking ahead? IMHO calling multibyte a hack would be great disservice to the developers of that extension. We don't call ext/pgsql a hack, simply because it's not builtin, do we? The extension is virtually a hack. Again, the developers of mbstring had to choose the option, adding support for multiple encodings to PHP by separating it as an extension, instead of integrating it into the core implementation because we always ought to manage backwards compatibilities. If I were starting a language from scratch today, I would make character encoding part of the string "zval" structure. IMHO that's where it belongs. As an alternative for PHP 5[.1], there is room for a "multibyte bit" in the zval that various functions can use to choose between "sizeof(byte)==sizeof(char)" and "sizeof(byte) < sizeof(char)" implementations. If you were designing a new language you wouldn't have legacy users who'd suffer (significantly) because of features added for other users. Well, the legacy users of PHP4 will significantly suffer for PHP5's new features. 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 Tue, 16 Dec 2003, Moriyoshi Koizumi wrote: > > If you were designing a new language you wouldn't have legacy users > > who'd suffer (significantly) because of features added for other > > users. > > Well, the legacy users of PHP4 will significantly suffer for > PHP5's new features. Uh? Where does this wisdom comes form? 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 2003/12/16, at 0:42, Derick Rethans wrote: On Tue, 16 Dec 2003, Moriyoshi Koizumi wrote: If you were designing a new language you wouldn't have legacy users who'd suffer (significantly) because of features added for other users. Well, the legacy users of PHP4 will significantly suffer for PHP5's new features. Uh? Where does this wisdom comes form? README.PHP4-TO-PHP5-THIN-CHANGES and anything I spotted in the current 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 Tue, 16 Dec 2003, Moriyoshi Koizumi wrote: > > On 2003/12/16, at 0:42, Derick Rethans wrote: > > > On Tue, 16 Dec 2003, Moriyoshi Koizumi wrote: > > > >>> If you were designing a new language you wouldn't have legacy users > >>> who'd suffer (significantly) because of features added for other > >>> users. > >> > >> Well, the legacy users of PHP4 will significantly suffer for > >> PHP5's new features. > > > > Uh? Where does this wisdom comes form? > > README.PHP4-TO-PHP5-THIN-CHANGES and anything I spotted in > the current code. I know there are changes, I was inquiring about the "significantly" in your statement. 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 December 15, 2003 10:36 am, Moriyoshi Koizumi wrote: > Well, the legacy users of PHP4 will significantly suffer for > PHP5's new features. How so? PHP 5 does break BC (especially for objects) but this is something that was talked about for years and the consensus is/was that the change is for the better. To my knowledge, majority of the new features in PHP5 are just that and have no side effects. Another alternative to moving fgetcsv()'s current implementation would be to add #ifdef HAVE_MBSTRING around php_mblen, which would do #define php_mblen(ptr, len) 1 if mbstring is not enabled. Personally, I'd prefer to have the function in mbstring and modified further to support multibyte delimiters and enclosures, which it does not do now due to performance considerations. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
Monday, December 15, 2003, 1:28:41 PM, you wrote: > Guys, > We have had this discussion before. There are two extremes to this issue. > The first is to always require the explicit __toString() call and the > second is to never require it and have all places in PHP whether it's > str_replace(), (string)$obj, $arr[$obj] to automatically convert to string. > The latter is problematic because it propagates to far too many places and > causes too much magic in my opinion. > I think the right trade off is to automatically convert it with "print" and > with concatenation. All the rest will require explicit calling. > It might not be your dream but it's a realistic approach. helly Mon Dec 15 11:59:21 2003 EDT Modified files: /php-src/tests/classes tostring.phpt /ZendEngine2zend.c zend_object_handlers.c zend_object_handlers.h Log: Reenable __tostring() magic for print,echo,concatenation,function naming... but not for other internal things. (...) Guys, please try php-cvs version and report any problems (or dislike) as soon as possible. regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString()
Marcus Boerger wrote: please try php-cvs version and report any problems (or dislike) as soon as possible. Neither a problem nor a dislike but I noted that __toString() is also called on exit($obj); Didn't check if there's more cases. - Chris -- 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)
Stig S. Bakken wrote: On Sun, 2003-12-14 at 00:28, Ilia Alshanetsky wrote: 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. So you think the right solution is to dismiss multibyte users and direct them to the hacks (mbstring etc) that have been used previously instead of thinking ahead? I see no example of him implying he wanted to "dismiss" multibyte users, he simply suggested mb_* versions of the string manipulation functions and pointed available facilities that people can use already. I support that idea, as having a mb_ version and a version without multibyte support gives everyone what they want. People who want multibyte strings have it, and people who want speed without multibyte strings still have that; everyone should be happy. Those who don't need multibyte strings (the majority, by a long shot) don't have to suffer any performance loss, while those in Asia can open that marketshare you speak of. If I were starting a language from scratch today, I would make character encoding part of the string "zval" structure. IMHO that's where it belongs. As an alternative for PHP 5[.1], there is room for a "multibyte bit" in the zval that various functions can use to choose between "sizeof(byte)==sizeof(char)" and "sizeof(byte) < sizeof(char)" implementations. - Stig -- 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 Mon, 15 Dec 2003, Derek Ford wrote: > I see no example of him implying he wanted to "dismiss" multibyte users, > he simply suggested mb_* versions of the string manipulation functions > and pointed available facilities that people can use already. I support > that idea, as having a mb_ version and a version without multibyte > support gives everyone what they want. People who want multibyte strings > have it, and people who want speed without multibyte strings still have > that; everyone should be happy. Those who don't need multibyte strings > (the majority, by a long shot) don't have to suffer any performance > loss, while those in Asia can open that marketshare you speak of. It is a dismissal in the sense that existing apps not written explicitly for multibyte support will not work for nearly half the users of PHP. We are not talking about a small group of users here. As Stig says, the correct solution would be to always store the encoding of the string right alongside the length of the string in the guts of PHP. Anything short of that is going to be a hack. PHP6 here we come... -Rasmus -- 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 15, 2003 06:36 pm, Rasmus Lerdorf wrote: > As Stig says, the correct solution would be to always store the encoding > of the string right alongside the length of the string in the guts of PHP. > Anything short of that is going to be a hack. PHP6 here we come... Then here is our first TODO for PHP6 :). But until then, please, let's try to avoid adding hacks that implement partial mb support in select functions. These hacks serve no one, many users loose scalability and other users get partial support that will likely prevent them from using the new functionality. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
