Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17776
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 10 Aug 2005 14:54:07 +0400
To: "Ron Korving" <r.korving@xit.nl>
Cc: internals@lists.php.net
Message-ID: <20050810145407.3917271d.antony@zend.com>
In-Reply-To: <1B.49.24081.1DAD9F24@pb1.pair.com>
References: <937066F0-AA5F-41E2-99A0-D74C7F44FFCA@gravitonic.com>
	<1B.49.24081.1DAD9F24@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP Unicode support design document
From: antony@zend.com (Antony Dovgal)

On Wed, 10 Aug 2005 12:45:27 +0200
"Ron Korving" <r.korving@xit.nl> wrote:

> This looks very promising, I'm impressed by the work you guys have done (big
> thumbs up).
> 
> There are a few issues/questions I have after reading your document:
> 
> 
> "Therefore, command such as 'print' and 'echo' automatically convert their
> arguments to the specified encoding. No automatic output encoding is
> performed for anything else."

That's actually something I wanted to ask about too.

Do we really need such kind of magic?

I think it may be pretty confusing when after echo'ing or print'ing a variable 
you can see one output, but after writing the very same variable into a file 
you can see something completely different.

IMO it's similar to what we have with __toString() ATM.
Yes, it's documented, but it's *still* confusing that there is some magic 
involved in one case and there is no magic in an other, almost similar case.

-- 
Wbr, 
Antony Dovgal