Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65548 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90527 invoked from network); 1 Feb 2013 00:34:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Feb 2013 00:34:28 -0000 Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.215.48 mail-la0-f48.google.com Received: from [209.85.215.48] ([209.85.215.48:40558] helo=mail-la0-f48.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 90/00-24912-29D0B015 for ; Thu, 31 Jan 2013 19:34:26 -0500 Received: by mail-la0-f48.google.com with SMTP id fq13so2358041lab.7 for ; Thu, 31 Jan 2013 16:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AykfDToXTtN89BLp9JuKhnnyvhdoZFIERM4hra5DR9Q=; b=MPS0ND7w1ViKHe894EY9l6NV8O9Wj1t3tZIQhEMuhHGHBOW2h2tGAvpqThjNHDgkFY rCl0wHUJ4owvzKU+68VO/+fglsrciUhkC0fByc6rkZUF7TPKQ04Uh8ZSJm/RhGrv6Tuw iyH2Jd/rBw8/qljD8DfS7BktaVhvi0miyjp1JAW8rw835TWOHm/ZlzO3/kdGlJayrAQf 4KuwN4CaoXAokia0gL8jVIK0GWw+QM6K9XQAQcKIS/fu7cWGPRlO4pmCeljrJXkOb7SO /yZzIhPqp4V0Th1KxyBLfyQRFVSaKi7z/qgStTzWb+1WQtJV092VlyqejDWDrZjsbTaH bHAQ== MIME-Version: 1.0 X-Received: by 10.112.51.175 with SMTP id l15mr3995183lbo.5.1359678863584; Thu, 31 Jan 2013 16:34:23 -0800 (PST) Received: by 10.112.138.131 with HTTP; Thu, 31 Jan 2013 16:34:23 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 01:34:23 +0100 Message-ID: To: Rasmus Schultz Cc: Etienne Kneuss , Anthony Ferrara , PHP internals Content-Type: multipart/alternative; boundary=f46d0401678fac2f5904d49ee781 Subject: Re: [PHP-DEV] rfc:foreach-non-scalar-keys From: nikita.ppv@gmail.com (Nikita Popov) --f46d0401678fac2f5904d49ee781 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 1:05 AM, Rasmus Schultz wrote: > I'm not sure how I came to that conclusion - did the description change > since I looked at it? > > I guess the title "foreach-non-scalar-keys" may have thrown me off - so > this isn't about arrays, or really even about foreach, but about the > Iterator interface. I'm not against that at all. > > I would suggest considering the addition of a second, distinct interface - > rather than a modification to the existing interface, which already does > what it's supposed to and works well, including the warning, which is > appropriate for the intended use of that interface with the foreach > statement. > > This alternative interface could have the opposite behavior - issuing a > warning if the returned key is not an object. I don't think there's a > legitimate use-case where mixing scalar and object keys would be a good > idea? (if there were, a single interface might be the only way to go.) > Please, don't make this more complicated than it is. This is just about removing an arbitrary engine limitation. And yes, obviously mixing different keys has applications, e.g. consider implementing a generalized hash type. It makes no sense whatsoever to implement the same thing with two classes implementing different interfaces. The only reason why this needs discussion is that allowing non string/int keys requires a change in the internal iterator API. Nikita --f46d0401678fac2f5904d49ee781--