Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25899 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14475 invoked by uid 1010); 29 Sep 2006 21:10:44 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 14460 invoked from network); 29 Sep 2006 21:10:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Sep 2006 21:10:44 -0000 Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 80.74.107.235 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from [80.74.107.235] ([80.74.107.235:39152] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 74/B3-15221-1DB8D154 for ; Fri, 29 Sep 2006 17:10:43 -0400 Received: (qmail 16676 invoked from network); 29 Sep 2006 21:09:22 -0000 Received: from office.zend.office (HELO ?192.168.16.109?) (192.168.16.109) by internal.zend.office with SMTP; 29 Sep 2006 21:09:22 -0000 Message-ID: <451D8BCC.1010507@zend.com> Date: Fri, 29 Sep 2006 14:10:36 -0700 Organization: Zend Technologies User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sara Golemon CC: internals@lists.php.net References: <03a49eb85c1b86038c5d127230bd3f78@gravitonic.com> <61923.208.195.234.254.1159463675.squirrel@www.l-i-e.com> <5F.60.15221.DAC6D154@pb1.pair.com> In-Reply-To: <5F.60.15221.DAC6D154@pb1.pair.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Per-request UG(unicode) From: stas@zend.com (Stanislav Malyshev) > Nooone is arguing that from the userspace side, having per-dir support for > setting the unicode flag is a good thing. It is. The question is: Is it > good enough to justify the soup that will become of the internal registries? I'm not sure there really would be a soup. Yes, there would be two copies of persistent system hashes - namely, class table and function table - and probably there would be a need to deal with other persistent tables like module lists in couple of places - but besides that there should be not much of a soup...