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
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_ versio
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 envir
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 L
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(),
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
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
>
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
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 d
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 w
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 o
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 solve
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/ZE
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/ h
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
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
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.
Control version
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
>
> Bull
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,
> > applicatio
20 matches
Mail list logo
