Re: Re: Str enhancement, final run

From: Date: Sun, 15 Jul 2001 17:44:02 +0000
Subject: Re: Re: Str enhancement, final run
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-60060@lists.php.net to get a copy of this message
Hi Andre, At 16:59 7/15/2001, André Langhorst wrote the following: -------------------------------------------------------------- >>Yes, I think that for strings we should limit it to ranges >>like $foo{4..6}, and it would be neat if we for arrays could >>do $foo[4..6]. ":" might be just as well as "..". It is more >>intuitive with ".." I think, but I also kind of like having a >>single character. > > >4:6 is more of a soccer result than intuitive ;) If it stands on its own, maybe. If it's part of $str[4:6], it's IMNSHO clear. I vote for a single-character separator. >$foo[$a] should return array(item) >$foo[$a..$n] returns array of items $a to $n I think that _this_ is somewhat more interesting. Consider the following code: $arr = array( 'foo' , 1 , array( 'bar' ) ) ; $item = $arr[0] ; Should $item contain array( 'foo' ) or 1? Do I get it right that you propose the former (array( 'foo' ))? That would surely break 99.9% of PHP code. As I wrote to Andi, I like the idea of equivalence (or close similarity) of arrays and strings. Just look how Python does it (ripped off a Python tutorial @ http://www.python.org/doc/current/tut/node5.html): >>> word = 'Help' + 'A' >>> word 'HelpA' >>> word[4] 'A' >>> word[0:2] 'He' [1] >>> word[2:4] 'lp' >>> word[:2] # The first two characters 'He' >>> word[2:] # All but the first two characters 'lpA' [2] >>> word[:2] + word[2:] 'HelpA' >>> word[:3] + word[3:] 'HelpA' >>> word[-1] # The last character 'A' >>> word[-2] # The last-but-one character 'p' >>> word[-2:] # The last two characters 'pA' >>> word[:-2] # All but the last two characters 'Hel' >>> word[-0] # (since -0 equals 0) 'H' [1] What I don't like on the way Python does this is the fact that positive upper bounds are 1-bound. That really confused me when I first looked at Python. [2] is a clear example of this (they call this FMPOV misfeature 'useful'!). What I would love to see in PHP is the Python slicing without the Python's quirks. Positive upper bounds should really be 0-bound. The rest of the things I dislike about slicing in Python PHP already does 'right': $s = 'hello' ; echo $s[10] ; # returns empty string (yields an exception # in Python) See also: http://www.python.org/doc/current/ref/subscriptions.html http://www.python.org/doc/current/ref/slicings.html Now, as for the PDF document and strings... (I should stress that I caught with this discussion only yesterday, so sorry if I repeat something that's been said already, and possibly dismissed as stupid. Also, the internals of Zend are way over my head, so treat this as a BFU's "rant".) I repeat, and can't stress it enough, that I really like the idea of equivalence of arrays and strings. Consider the following code: $s = 'hello' ; foreach( $s as $c ) { echo "$c\n" ; } 4.0.6RC1 emits a E_WARNING, and outputs nothing. What I'd like to see is h e l l o I understand that without moving strings and arrays _closer_ together instead of what seems to be a common agreement - make them more distinct - this would require a hack for foreach(). The PDF specifically mentions: : There is an ambiguity in today’s sharing of array offsets : syntax for both strings and arrays. In code such as : $str[0] = ‘a’; where $str is an empty string (due to earlier : PHP 4 and PHP 3 behavior) $str is treated as an array and : therefore the above statement would result in $str[0] being : converted to an array and having its offset 0 being set to : the string “a”. However, some people would expect the result : to be $str as the string value “a”. Now, is a whole new syntax really needed where all is needed is an explicit cast? I mean this could be disambiguated the following way (warning: this may be nonsense, I'm not very familiar with C, and don't know how fast/slow, easy/hard to implement this would be): $foo = '' ; $foo[0] = 'a' ; # $foo is a string containing single 'a' char $foo = array() ; $foo[0] = 'a' ; # $foo is an array containg single value, 'a' So the type of $foo after the assignment to its index would be determined from it's type prior to this assignment. The way PHP behaves currently isn't ideal either: $x = 0 ; $x[0] = 10 ; # Warning: Cannot use a scalar value as an array in ... var_dump( $x ) ; # int(0) This is IMO a big inconsistency. The question here is how much code would it break if assignment into an index would keep the type of the variable (instead of current behavior where PHP converts the empty string to array)? I know it wouldn't break more than ~1% of my code (the oldest stuff), but then again, Andrei once asked me "what good is a scripting language if you need stuff like that?". :) So this question should probably be asked in user lists. >it seems obvious to implement this for arrays, array_slice() and substr() both have identical >syntax. >you could easily cut bigger arrays into smaller ones then, without hazzle. > >any opinions about array slicing in the language itself? IMO all points discussed for string >slicing also apply to array slicing Agreed. >andré cynic@mail.cz ------------- And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7

« previous php.dev (#60060) next »