Re: [PHP-DEV] Re: Str enhancement, final run
On Sun, Jul 15, 2001 at 01:13:04AM +0200, Cynic wrote:
As for the Andre's suggestions, I like Python's ranges in both
lists and strings (they use colon instead of two dots). I
some details of it unintuitive, but don't remember what it was
exactly as it's been some time since I touched Python though.
I can look it up if anyone's interested.
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.
Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Str enhancement, final run
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 ;)
$foo[$a]
should return array(item)
$foo[$a..$n]
returns array of items $a to $n
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
andré
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Str enhancement, final run
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 todays 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
Re: [PHP-DEV] Re: Str enhancement, final run
Hi there,
excuse my ignorance, but could someone provide me w/ some
hints as to the origin of this thread? I must've missed it
(just returned from vacation). Since I haven't seen prior
messages in this/related thread(s), I might be off base here.
Sorry if this is the case.
Now, some time ago (1.5y) when I began exploring PHP and
stumbled upon something unintuitive (had to do w/ strings
being similar to arrays but not completely equivalent...)
Andi told me strings would be eventually made more different
from arrays.
Now, I might be the only one, but I actually like the idea of
equivalence of strings and arrays. For example, I'd like to
be able to foreach() a string just like it was an array (last
time I checked the behavior was st. like 'string' being used
as if it was array('string') - I'd prefer array('s','t','r',
'i','n','g').
As for the Andre's suggestions, I like Python's ranges in both
lists and strings (they use colon instead of two dots). I
some details of it unintuitive, but don't remember what it was
exactly as it's been some time since I touched Python though.
I can look it up if anyone's interested.
Oh, where can I subscribe to [EMAIL PROTECTED]? Seems like
that's where the fun is. :)
At 18:38 7/10/2001, Andi Gutmans wrote the following:
--
At 06:00 PM 7/10/2001 +0200, André Langhorst wrote:
As it were Andi's last words, is it the finial decison now just to implement $foo{x}
to retrieve a single char?
I'm asking this again, because it will be irreversible because it is not compatible
with substr($foo,x) == $foo{x}!!!
And as I still do not agree that substr($foo,4,6) should be better than
$foo{4,6} I now have another (taken and modified from Zeev or Andi) offer, which *is
intuitive*:
What about the range proposals? $foo{4..6} where $foo{6..} would mean to the end, no
negative numbers, nothing else but at least that would simplify string processing a
bit (although I am still in favor for the substr() solution).
I think even Zeev would agree that this is intuitive ;)
So far we have:
$foo{x} get char at pos x
$foo{x..} get chars from pos x to the end
$foo{x..y} get chars from pos x to y
This option looks nice but I don't like the extensions mentioned below. I still think
that people who need more complicated stuff can use substr(). But I know many don't
agree with me so I prefer to wait a while with the discussion until we start
advancing a bit in the Engine 2 implementation and then we will also have more of a
technical basis to judge not only what is nice but also what is technically feasible.
The only thing I think is pretty sure is that $foo{x} will work :)
Andi
Now what if we do not know the position of the last character?
$foo{x..-5} get chars from pos x to the minus 5
I tried to interprete this differently but I failed, isn't this called intuitive?
As an alternative we even modify it to
$foo{x..|} and $foo{x..|-4}
if anyone feels better with it...
Comments welcome,
andré
ps. I do not remember the engine2 email address, if anyone could forward it...
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote--
[EMAIL PROTECTED]
-
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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run
On Tue, Jul 10, 2001 at 08:04:42PM +0200, Jeroen van Wolffelaar wrote:
I've said it before, but I *really* am convinced now, that we should:
- At least allow $str{index} (while _deprecating_ the array $str[ ] indices)
- _possibly_ also allowing $str{start..end}
- and if the above is allowed, then I think you should also allow
$str{..end} and $str{start..}
But *nothing else*.
+1
Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Str enhancement, final run
On Tue, 10 Jul 2001, André Langhorst wrote:
nah, you know waiting turns developers into killer-machines ;)
something more to think about...
$foo{${a$i}}
$foo{$i++..$i}
$foo{($moo ? $zoo:$boo)..$roo}
$foo{super_function($moo)..substr($doh::zoo)-4}
I state that is better to simply implement negative indices than
allowing all these kinds of perlish code (what would follow if we'd
allow substr()ingin in {}
or should we allow all this sorts of statements and operators and functions?
I think we should not allow this, use substr() if you need more
functionality. Stick to very simple things with the {} stuff.
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Str enhancement, final run
I think we should not allow this, use substr() if you need more
functionality. Stick to very simple things with the {} stuff.
ah hell, I think Andi not even thought at using substr() within {}.
then my argumentation is something like void ;)
these examples were meant perlish and will do harm of course.
For me they're (negative indices and substr() method) completely
interchangeable and as *this* range-solutions isn't incompatible with
adding the negative-indices-feature afterwards, *I won't complain* if
it'll not go in at first and I think others won't.
example
here a silly-but-simple-example(TM) how it *could* look like:
$foo='peterralf'.fill_in_rubbish_string().'!';
print 'hello '.$foo{0..4}.', hello '.$foo{5..8}.' is this
rubbish:'.substr($foo,9,-1).'?';
print 'hello '.$foo{0..4}.', hello '.$foo{5..8}.' is this
rubbish:'.$foo{9..-1}.'?';
/example
this *almost* looks identical, why not simply use the {} syntax here?
ok. if I was Andi or Zeev I could also argue, why not use substr() here,
that's a point, because I don't see how this would be any harm.
as I stated before I won't complain any longer about this as we possibly
have found an agreeable solution regarding range-indices.
andré
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run
I've said it before, but I *really* am convinced now, that we should:
- At least allow $str{index} (while _deprecating_ the array $str[ ] indices)
- _possibly_ also allowing $str{start..end}
- and if the above is allowed, then I think you should also allow
$str{..end} and $str{start..}
But *nothing else*.
Greetz,
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run
I had suggested the start end construct, but was rejected by Zeev due to performance
reasons,
and that nobody in the history of php has ever need this : )
-Jason
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Derick Rethans [EMAIL PROTECTED]; André Langhorst [EMAIL PROTECTED]
Cc: Andi Gutmans [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED];
[EMAIL PROTECTED]; Stanislav Malyshev [EMAIL PROTECTED];
Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 10, 2001 1:04 PM
Subject: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run
I've said it before, but I *really* am convinced now, that we should:
- At least allow $str{index} (while _deprecating_ the array $str[ ] indices)
- _possibly_ also allowing $str{start..end}
- and if the above is allowed, then I think you should also allow
$str{..end} and $str{start..}
But *nothing else*.
Greetz,
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
