Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26045 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57934 invoked by uid 1010); 12 Oct 2006 21:27:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 57919 invoked from network); 12 Oct 2006 21:27:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Oct 2006 21:27:00 -0000 X-Host-Fingerprint: 207.126.230.225 nat-dip4.corp.yahoo.com Received: from [207.126.230.225] ([207.126.230.225:7655] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0C/0A-22864-223BE254 for ; Thu, 12 Oct 2006 17:27:00 -0400 Message-ID: <0C.0A.22864.223BE254@pb1.pair.com> To: internals@lists.php.net References: <638D2DBE-1C6E-46F4-B1FF-1B3E16F0E889@gravitonic.com> Date: Thu, 12 Oct 2006 14:26:56 -0700 Lines: 20 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-RFC2646: Format=Flowed; Original X-Posted-By: 207.126.230.225 Subject: Re: cast_object handler patch From: pollita@php.net ("Sara Golemon") >I discovered that using convert_to_(string|unicode)_with_converter() > on objects still used runtime encoding instead of the specified > converter. Turns out it's because cast_object handler has no clue > about the converter passed to the macro. This patch implements a fix > via adding an extra generic pointer parameter to cast_object that can > be used by various types as necessary. If no one objects, I'll commit > the change soon. > How does this impact userspace __toString() handlers? Would we pass the encoding from the converter to them? function __toString($encoding) { } Do we need __toUnicode($encoding) as well? Would we just let the user pass back *whatever* type then convert as needed in the internal cast handler? -Sara