Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68411 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37314 invoked from network); 8 Aug 2013 01:03:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Aug 2013 01:03:38 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:33684] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E1/65-06453-A6EE2025 for ; Wed, 07 Aug 2013 21:03:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0CD4E500AF; Wed, 7 Aug 2013 21:03:36 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C0B2C5008E; Wed, 7 Aug 2013 21:03:35 -0400 (EDT) Message-ID: <5202EE67.5020307@sugarcrm.com> Date: Wed, 07 Aug 2013 18:03:35 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <5202AF52.9060200@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] "php_serialize" session serialize handler From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Personally, I would not use numeric index. > However, users are expecting it to work and there is no way to raise I don't think it is reasonable to expect it to work, it never worked, it never was documented to work and there's no real use case for it. > The limitation is come from register_globals and it has nasty problem. I don't see how is it a nasty problem if there's actually no good reason to do this. If there is a good reason to do it, please tell what it is. > Most users don't care what serializer does and users who may have > BC issue can use old serializers anytime. Using old serializer is work which we would make users do for improvement that practically nobody needs and that does not provide any actual improvement that can not easily be achieved otherwise. Breaking BC just because somebody somewhere needs an exotic feature that can easily be worked around doesn't look like a good idea to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227