Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53527 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87047 invoked from network); 23 Jun 2011 06:09:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jun 2011 06:09:19 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.27 out3.smtp.messagingengine.com Received: from [66.111.4.27] ([66.111.4.27:41708] helo=out3.smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C7/E5-43757-D88D20E4 for ; Thu, 23 Jun 2011 02:09:18 -0400 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4DE1821044 for ; Thu, 23 Jun 2011 02:09:15 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 23 Jun 2011 02:09:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=J42M9Set0iPqcVoC+B7tWQhqexc=; b=lLb2FB92mNeVYie091VMHrYkktcMJ4DQjj+VBiGj0svKhE5KlalZhMm22vIawbBtLeO0gGHroFaqHmDN4Dl8MjxGHSgcSGntxg19sdl4SquxO5FbcW+nW/z7kmytN/If5ABJshsh/dENuC8OhueCPaujx26nIVpkllJLUCxi6s8= X-Sasl-enc: +2aM0xQCjLFLNTcu13myjWq77dOngxna2BUa6lUsFrfN 1308809355 Received: from linux-nkec.site (c-71-57-95-65.hsd1.il.comcast.net [71.57.95.65]) by mail.messagingengine.com (Postfix) with ESMTPSA id ED6D744BF1B for ; Thu, 23 Jun 2011 02:09:14 -0400 (EDT) Message-ID: <4E02D95F.7030303@garfieldtech.com> Date: Thu, 23 Jun 2011 01:12:47 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] foreach() for strings From: larry@garfieldtech.com (Larry Garfield) On 06/20/2011 10:25 AM, John Crenshaw wrote: > Doing this with an explicit iterator object is a fine idea. The syntax > becomes something like: > foreach(new TextIterator($s, 'UTF8') as $pos=>$c) > { > ... > } > > On the other hand, I think that trying to support iteration without using an iterator object to mediate would be a disaster, and I'm opposed to doing something like that because: > 1. The code just looks wrong. PHP developers are generally insulated from the char-arrayness of strings. In addition, since PHP isn't typesafe, the code becomes highly ambiguous. Is the code iterating an array, or a string? It is very hard to tell just by looking. It may be convenient to write, but it's certainly not convenient to read or maintain later. On the other hand, with a mediating iterator object, the intent becomes obvious, and the code is highly readable. > 2. The odds of iterating any given string are slim at best. Supporting current, key, next, etc. would require the string object internally to get bloated with additional unnecessary data that is almost never used. This bloat isn't a single int either. For optimal performance it would need to consist of no less than two size_t (char position and binary position), and one encoding indicator. > 3. Iteration cannot work without knowing which encoding to use for the string. Is it UTF8? UTF16? UTF7? Binary or some single byte encoding? Some other exotic wide encoding? Without an iterator object in the middle, there is no way to specify this encoding. Always treating this as binary would also be a mistake, since this is almost certainly never actually the correct behavior, even though it may often appear to behave correctly with simple inputs. > 4. I've had simple mistakes caught numerous times when foreach complains about getting a scalar rather than an array. So far, it has been exactly right every time. Allowing strings to be iterated would, in the name of convenience, increase the probability of stupid mistakes evading detection. Even worse, the code itself would look logically correct until the developer finally realizes that they have a string and not an array. Errors like this are probably far more common in most projects than the need to iterate a string, so making this change hurts debugging in the common case, for the sake of syntactic sugar in the rare case. Not a good trade. > > John Crenshaw > Priacta, Inc. I would echo John's statements here. foreach() directly iterating a string is going to make my life substantially harder. I work in array-heavy systems, and "bad first argument for foreach()" is already a hard enough error to track down. It means "somewhere, somehow, you put a string where you meant to put an array. GLWT." Adding automatic string iteration would take away even that error message and leave me with no way to figure out why my code is randomly misbehaving. Just looking at the code, I would have no way of knowing that such a bug lurks within. That's the downside of a weakly typed but still typed language. A proper iterator class, however, makes a great deal of sense. It could be implemented user-space fairly easily, no doubt, but for strings of any appreciable size (like the OP seems to be talking about for code parsing) I suspect performance and memory usage would be far better if implemented in C. Whether it's a byte-based or character-set-sensitive-character-based iterator... honestly I don't care as long as it's documented properly. --Larry Garfield