- Original Message -
From: "Shane Caraveo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 01, 2004 1:41 PM
Subject: Re: [PHP-DEV] Re: Negative string offset support
--- snip --
> Having my python hat on...
>
> There also is this whic
Rasmus Lerdorf wrote:
On Sun, 31 Oct 2004, moshe doron wrote:
where the problem about 'taking it ever further'? I'm +1 for {-1}
and more +1 for {-4,2} python likeness.
That starts getting confusing.
Having my python hat on...
(some of this is just general comment after reading too much of this th
>> Substr_replace() for the purpose of changing one char is like using a
>> tank for a fly swatter, it may work but it is extremely inefficient.
>>
> the example wasn't clear but I stated with substr_replace() there is no
> need
> for ranges in {}.
>
I like {$s,$l} and/or {$s:$e} for read, but I
So,
the example wasn't clear but I stated with substr_replace() there is no need
for ranges in {}.
Andrey
Ilia Alshanetsky wrote:
Substr_replace() for the purpose of changing one char is like using a
tank for a fly swatter, it may work but it is extremely inefficient.
Ilia
Andrey Hristov wrote:
Substr_replace() for the purpose of changing one char is like using a
tank for a fly swatter, it may work but it is extremely inefficient.
Ilia
Andrey Hristov wrote:
just to mention that there is substr_replace()
php -r '$a="abc"; var_dump(substr_replace($a, "d", -1));'
IMO at least there is no
just to mention that there is substr_replace()
php -r '$a="abc"; var_dump(substr_replace($a, "d", -1));'
IMO at least there is no need for range like $a{-4:2}
Andrey
Ilia Alshanetsky wrote:
IMO {-1} syntax is not only faster but simpler to use then the
equivalent substr() (for read) or $a[strlen(
I honestly don't really care about the performance side of things, I'd
be very surprised if this sort of calculation is going to be in the top
5 bottlenecks of an application. However, from a development point of
view I do find $a{-1} a much shorter and cleaner way of calculating an
end-of-string o
IMO {-1} syntax is not only faster but simpler to use then the
equivalent substr() (for read) or $a[strlen($a) - 1] (for write). While
my reasons are primarily performance based, I think that most people
would find the {-1} simpler to use as well.
Ilia
Sterling Hughes wrote:
i hope not. this
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
On 30 October 2004 02:03, Andi Gutmans wrote:
> Nah that patch won't do because it'll effect [] also.
> It's more complicated than that. I've tried separating them in the
> past and
On Sun, 31 Oct 2004, Sterling Hughes wrote:
> i hope not. this should be about what's cool for developers, the
> speed increase is not a compelling reason.. the debate is "does this
> make code easier to read/write/maintain?" I think it doesn't, and
> therefore am against it.
And I agree with
i hope not. this should be about what's cool for developers, the
speed increase is not a compelling reason.. the debate is "does this
make code easier to read/write/maintain?" I think it doesn't, and
therefore am against it.
-sterling
On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger <[EMAIL
Hello Wez,
well it would. However 5.1 aims to be a major speed improvement and that's
what the idea is about.
best regards
marcus
Monday, November 1, 2004, 2:29:46 AM, you wrote:
> Doesn't substr($a, -1) work ?
> --Wez.
> On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver <[EMAIL PROTECTED]> w
Wez Furlong wrote:
Doesn't substr($a, -1) work ?
I knew that looked funny, but couldn't figure out why for some reason,
thanks for the good catch.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Doesn't substr($a, -1) work ?
--Wez.
On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver <[EMAIL PROTECTED]> wrote:
> It would reduce the errors I inevitably get
> whenever using a complex feature like substr(). The three choices:
>
> 1) substr($a, strlen($a) - 1);
> 2) $a{strlen($a) - 1}
> 3) $a{-
Marcus Boerger wrote:
Hello Rasmus,
Sunday, October 31, 2004, 11:27:40 PM, you wrote:
On Sun, 31 Oct 2004, moshe doron wrote:
where the problem about 'taking it ever further'?
I'm +1 for {-1} and more +1 for {-4,2} python likeness.
That starts getting confusing. I assume that translates to the 3
Hello Rasmus,
Sunday, October 31, 2004, 11:27:40 PM, you wrote:
> On Sun, 31 Oct 2004, moshe doron wrote:
>> where the problem about 'taking it ever further'?
>> I'm +1 for {-1} and more +1 for {-4,2} python likeness.
> That starts getting confusing. I assume that translates to the 3rd and
> 4
On Sun, 31 Oct 2004, moshe doron wrote:
> where the problem about 'taking it ever further'?
> I'm +1 for {-1} and more +1 for {-4,2} python likeness.
That starts getting confusing. I assume that translates to the 3rd and
4th chars from the end of the string. And, to verify that I went and
look
At 08:02 30/10/2004, Ilia Alshanetsky wrote:
Derick Rethans wrote:
- Adding new language constructs in mini releases is IMO not the way to
go as it will make it possible impossible to run script that use this
new construct not even parse on PHP 5.0.x servers. Adding normal new
functions does
Derick Rethans wrote:
On Fri, 29 Oct 2004, Andi Gutmans wrote:
Yeah, I also thought the word "need" is a bit strong :) It's more like
"syntactic sugar which is nice-to-have"
As I just told Ilia on IRC, I think we should not add this (now) for a
couple of reasons:
- Adding new language constructs
Ilia Alshanetsky wrote:
I am well aware that at this point PHP has no separation between [] and
{} as far as string offsets go. My initial suggestion was to add the
support for negative offsets and not to limit it to a particular
construct. Given that this is intended for strings only, I readily
Andrey Hristov wrote:
Andy mentioned that he tried in the past to separate {} and [] but after
some unsuccess he left the idea of separating. So, the patch definitely
won't be 2-3 lines of code.
I am well aware that at this point PHP has no separation between [] and
{} as far as string offsets go.
Ilia Alshanetsky wrote:
Derick Rethans wrote:
How can you *need* this, you can use substr() just fine.
Almost no peace of functionality in PHP in unique, some extensions
duplicate core/standard functionality and vice versa. Usually the "core"
offers a simpler access to a resource and full pledg
Derick Rethans wrote:
- Adding new language constructs in mini releases is IMO not the way to
go as it will make it possible impossible to run script that use this
new construct not even parse on PHP 5.0.x servers. Adding normal new
functions does not have this problem of course, as those scr
Derick Rethans wrote:
How can you *need* this, you can use substr() just fine.
Almost no peace of functionality in PHP in unique, some extensions
duplicate core/standard functionality and vice versa. Usually the "core"
offers a simpler access to a resource and full pledged extensions
gives the
"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Nah that patch won't do because it'll effect [] also.
> It's more complicated than that. I've tried separating them in the past
> and it was annoying (and didn't have time to finish it off).
>
> Andi
>
True... I should
Derick Rethans wrote:
On Fri, 29 Oct 2004, Greg Beaver wrote:
Ilia Alshanetsky wrote:
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = "123"; echo $a[-1]; // would print 3
I don't think we s
Nah that patch won't do because it'll effect [] also.
It's more complicated than that. I've tried separating them in the past and
it was annoying (and didn't have time to finish it off).
Andi
At 05:51 PM 10/29/2004 -0700, Sara Golemon wrote:
> - Adding new language constructs in mini releases is
> - Adding new language constructs in mini releases is IMO not the way to
> go as it will make it possible impossible to run script that use this
> new construct not even parse on PHP 5.0.x servers. Adding normal new
> functions does not have this problem of course, as those scripts are
> s
On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote:
>
> > Yeah, I also thought the word "need" is a bit strong :) It's more like
> > "syntactic sugar which is nice-to-have"
>
> As I just told Ilia on IRC, I think we should not add this (now) for a
> coupl
On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote:
>
> > Yeah, I also thought the word "need" is a bit strong :) It's more like
> > "syntactic sugar which is nice-to-have"
>
> As I just told Ilia on IRC, I think we should not add this (now) for a
> coupl
I think we should not follow this discussion on internals@ and instead
we should have a subcommittee to study whether or not the word need
was appropriate in the context of the substring operator, or whether
in fact, "would be nice to have, but might be able to continue living"
would've been a more
On Fri, 29 Oct 2004, Andi Gutmans wrote:
> Yeah, I also thought the word "need" is a bit strong :) It's more like
> "syntactic sugar which is nice-to-have"
As I just told Ilia on IRC, I think we should not add this (now) for a
couple of reasons:
- Adding new language constructs in mini releases
At 01:05 AM 10/30/2004 +0200, Derick Rethans wrote:
On Fri, 29 Oct 2004, Greg Beaver wrote:
> Ilia Alshanetsky wrote:
> > I am wondering what are people's opinions on adding support for negative
> > string offsets that could be used to access data from the end of a
string.
> >
> > Ex. $a = "123";
On Fri, 29 Oct 2004, Greg Beaver wrote:
> Ilia Alshanetsky wrote:
> > I am wondering what are people's opinions on adding support for negative
> > string offsets that could be used to access data from the end of a string.
> >
> > Ex. $a = "123"; echo $a[-1]; // would print 3
> >
> > I don't think
34 matches
Mail list logo
