Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » substr/array_slice in [] »

substr/array_slice in []

php.internals

Alexey Zakhlestin

18 years ago
Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a phrase "For both strings and arrays, the [] operator will support substr()/array_slice() functionality" will it appear in php5.x (php 5.3)?
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Ilia A.

18 years ago
This was not on the table and the time of the 5.3 discussion, I for one think its a bit too much magic. On 1-Oct-07, at 7:30 AM, Alexey Zakhlestin wrote:
> Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a > phrase "For both strings and arrays, the [] operator will support > substr()/array_slice() functionality" > > will it appear in php5.x (php 5.3)? > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Ilia Alshanetsky

Antony Dovgal

18 years ago
On 01.10.2007 16:32, Ilia Alshanetsky wrote:
> This was not on the table and the time of the 5.3 discussion, I for > one think its a bit too much magic.
Yeah, too Perl-ish for me.
-- Wbr, Antony Dovgal

Jeff Griffiths

18 years ago
Antony Dovgal wrote:
> On 01.10.2007 16:32, Ilia Alshanetsky wrote: >> This was not on the table and the time of the 5.3 discussion, I for >> one think its a bit too much magic. > > Yeah, too Perl-ish for me.
Actually, it's a lot like Python list slicing, which is a great feature and a clear enough syntax. cheers, Jeff

Cristian Rodriguez

18 years ago
2007/10/1, Antony Dovgal <tony@daylessday.org>:
> Yeah, too Perl-ish for me.
=) I dont see the need of implementing this either.
-- http://www.kissofjudas.net/

Stanislav Malyshev

18 years ago
Alexey Zakhlestin wrote:
> Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a > phrase "For both strings and arrays, the [] operator will support > substr()/array_slice() functionality" > > will it appear in php5.x (php 5.3)?
I think since we do have substr/array_slice there's no need to overload [] operator.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Andrei Zmievski

18 years ago
It's on my TODO list. -Andrei Alexey Zakhlestin wrote:

Martin Alterisio

18 years ago
Sorry to bother, I have a few questions on this matter. How will this impact on the SPL ArrayAccess and related interfaces and objects? Will there be an interface to this functionality? If so, how will ranges be passed through to this interface? Will this be consistent with substr() and array_slice() if used with an ArrayAccess implementation? Thank you and sorry for the bother. Regards, Martin Alterisio 2007/10/1, Alexey Zakhlestin <indeyets@gmail.com>:

Stanislav Malyshev

18 years ago
> Sorry to bother, I have a few questions on this matter. > How will this impact on the SPL ArrayAccess and related interfaces and > objects?
That's the problem with such syntax - one would expect it works with ArrayAccess and it starts to be complicated...
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Alexey Zakhlestin

18 years ago
On 10/1/07, Martin Alterisio <malterisio777@gmail.com> wrote:
> Sorry to bother, I have a few questions on this matter. > How will this impact on the SPL ArrayAccess and related interfaces and > objects? > Will there be an interface to this functionality? > If so, how will ranges be passed through to this interface? > Will this be consistent with substr() and array_slice() if used with an > ArrayAccess implementation?
I guess it can be made to work with current ArrayAccess, but result will be quite slow. (it will need to query requested elements one-by-one and recombine those in array) But adding another interface can solve the problem. Ranges can be passed exactly the way they are passed to [] operator public function rangeGet($start, $length); public function rangeSet($start, $length, array $data);
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Martin Alterisio

18 years ago
2007/10/2, Alexey Zakhlestin <indeyets@gmail.com>:
> > On 10/1/07, Martin Alterisio <malterisio777@gmail.com> wrote: > > Sorry to bother, I have a few questions on this matter. > > How will this impact on the SPL ArrayAccess and related interfaces and > > objects? > > Will there be an interface to this functionality? > > If so, how will ranges be passed through to this interface? > > Will this be consistent with substr() and array_slice() if used with an > > ArrayAccess implementation? > > I guess it can be made to work with current ArrayAccess, but result > will be quite slow. (it will need to query requested elements > one-by-one and recombine those in array) > > But adding another interface can solve the problem. Ranges can be > passed exactly the way they are passed to [] operator > > public function rangeGet($start, $length); > public function rangeSet($start, $length, array $data); > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ >
In that case rangeSet shouldn't have the third argument type hinted. The supplied data could be an ArrayAccess implementor.

Larry Garfield

18 years ago
On Tuesday 02 October 2007, Alexey Zakhlestin wrote:
> On 10/1/07, Martin Alterisio <malterisio777@gmail.com> wrote: > > Sorry to bother, I have a few questions on this matter. > > How will this impact on the SPL ArrayAccess and related interfaces and > > objects? > > Will there be an interface to this functionality? > > If so, how will ranges be passed through to this interface? > > Will this be consistent with substr() and array_slice() if used with an > > ArrayAccess implementation? > > I guess it can be made to work with current ArrayAccess, but result > will be quite slow. (it will need to query requested elements > one-by-one and recombine those in array) > > But adding another interface can solve the problem. Ranges can be > passed exactly the way they are passed to [] operator > > public function rangeGet($start, $length); > public function rangeSet($start, $length, array $data);
Here's the question I see. Right now, does an ArrayAccess object work with array_slice()? If so, then [2, 5] syntax would be just some nice syntactic sugar. If not, then it becomes a powerful new feature, and implementing it on normal arrays and strings becomes just a matter of consistent syntax. Personaly I kinda like it, but I know I'm not the one coding it. :-)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Alexey Zakhlestin

18 years ago
On 10/5/07, Larry Garfield <larry@garfieldtech.com> wrote:
> Here's the question I see. Right now, does an ArrayAccess object work with > array_slice()? If so, then [2, 5] syntax would be just some nice syntactic > sugar. If not, then it becomes a powerful new feature, and implementing it > on normal arrays and strings becomes just a matter of consistent syntax.
currently, array_slice doesn't work with ArrayAccess
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Derick Rethans

18 years ago
On Thu, 4 Oct 2007, Larry Garfield wrote:
> On Tuesday 02 October 2007, Alexey Zakhlestin wrote: > > On 10/1/07, Martin Alterisio <malterisio777@gmail.com> wrote: > > > Sorry to bother, I have a few questions on this matter. > > > How will this impact on the SPL ArrayAccess and related interfaces and > > > objects? > > > Will there be an interface to this functionality? > > > If so, how will ranges be passed through to this interface? > > > Will this be consistent with substr() and array_slice() if used with an > > > ArrayAccess implementation? > > > > I guess it can be made to work with current ArrayAccess, but result > > will be quite slow. (it will need to query requested elements > > one-by-one and recombine those in array) > > > > But adding another interface can solve the problem. Ranges can be > > passed exactly the way they are passed to [] operator > > > > public function rangeGet($start, $length); > > public function rangeSet($start, $length, array $data); > > Here's the question I see. Right now, does an ArrayAccess object work with > array_slice()? If so, then [2, 5] syntax would be just some nice syntactic > sugar.
It doesn't matter if it works with array_slice() or not. [x] works with ArrayAccess, so you'd expect [x,y] to work as well otherwise it's inconsistent. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Marcus Börger

18 years ago
Hello Larry, ArrayAccess is not designed to work in any array functions and we explicitly decided against going that route. We wanted ArrayAccess to support the array syntax, so [x,y] should be supported if we want that. However I agree that this kind of slicing is a bit too perlish or pythonish. marcus Friday, October 5, 2007, 3:05:30 AM, you wrote:
> On Tuesday 02 October 2007, Alexey Zakhlestin wrote: >> On 10/1/07, Martin Alterisio <malterisio777@gmail.com> wrote: >> > Sorry to bother, I have a few questions on this matter. >> > How will this impact on the SPL ArrayAccess and related interfaces and >> > objects? >> > Will there be an interface to this functionality? >> > If so, how will ranges be passed through to this interface? >> > Will this be consistent with substr() and array_slice() if used with an >> > ArrayAccess implementation? >> >> I guess it can be made to work with current ArrayAccess, but result >> will be quite slow. (it will need to query requested elements >> one-by-one and recombine those in array) >> >> But adding another interface can solve the problem. Ranges can be >> passed exactly the way they are passed to [] operator >> >> public function rangeGet($start, $length); >> public function rangeSet($start, $length, array $data);
> Here's the question I see. Right now, does an ArrayAccess object work with > array_slice()? If so, then [2, 5] syntax would be just some nice syntactic > sugar. If not, then it becomes a powerful new feature, and implementing it > on normal arrays and strings becomes just a matter of consistent syntax.
> Personaly I kinda like it, but I know I'm not the one coding it.
> -- > Larry Garfield AIM: LOLG42 > larry@garfieldtech.com ICQ: 6817012
> "If nature has made any one thing less susceptible than all others of > exclusive property, it is the action of the thinking power called an idea, > which an individual may exclusively possess as long as he keeps it to > himself; but the moment it is divulged, it forces itself into the possession > of every one, and the receiver cannot dispossess himself of it." -- Thomas > Jefferson
Best regards, Marcus

Larry Garfield

18 years ago
I have no love for Perl (and a rather strong dislike of it), but I have to agree with those who say that "looks like Perl" is a lame reason to reject something. PHP's object system looks an awful lot like Java, too. That doesn't make it bad. "Too unreadable", "not approachable enough", "too inflexible", etc. are perfectly valid reasons to reject a syntax. "Looks like <insert language here>" is not, I content, one of them. On Saturday 06 October 2007, Marcus Boerger wrote:
> Hello Larry, > > ArrayAccess is not designed to work in any array functions and we > explicitly decided against going that route. We wanted ArrayAccess to > support the array syntax, so [x,y] should be supported if we want that. > However I agree that this kind of slicing is a bit too perlish or > pythonish. > > marcus > > Friday, October 5, 2007, 3:05:30 AM, you wrote: > > On Tuesday 02 October 2007, Alexey Zakhlestin wrote: > >> On 10/1/07, Martin Alterisio <malterisio777@gmail.com> wrote: > >> > Sorry to bother, I have a few questions on this matter. > >> > How will this impact on the SPL ArrayAccess and related interfaces and > >> > objects? > >> > Will there be an interface to this functionality? > >> > If so, how will ranges be passed through to this interface? > >> > Will this be consistent with substr() and array_slice() if used with > >> > an ArrayAccess implementation? > >> > >> I guess it can be made to work with current ArrayAccess, but result > >> will be quite slow. (it will need to query requested elements > >> one-by-one and recombine those in array) > >> > >> But adding another interface can solve the problem. Ranges can be > >> passed exactly the way they are passed to [] operator > >> > >> public function rangeGet($start, $length); > >> public function rangeSet($start, $length, array $data); > > > > Here's the question I see. Right now, does an ArrayAccess object work > > with array_slice()? If so, then [2, 5] syntax would be just some nice > > syntactic sugar. If not, then it becomes a powerful new feature, and > > implementing it on normal arrays and strings becomes just a matter of > > consistent syntax. > > > > Personaly I kinda like it, but I know I'm not the one coding it. > > > > -- > > Larry Garfield AIM: LOLG42 > > larry@garfieldtech.com ICQ: 6817012 > > > > "If nature has made any one thing less susceptible than all others of > > exclusive property, it is the action of the thinking power called an > > idea, which an individual may exclusively possess as long as he keeps it > > to himself; but the moment it is divulged, it forces itself into the > > possession of every one, and the receiver cannot dispossess himself of > > it." -- Thomas Jefferson > > Best regards, > Marcus
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Antony Dovgal

18 years ago
On 06.10.2007 22:38, Larry Garfield wrote:
> I have no love for Perl (and a rather strong dislike of it), but I have to > agree with those who say that "looks like Perl" is a lame reason to reject > something. PHP's object system looks an awful lot like Java, too. That > doesn't make it bad. > > "Too unreadable", "not approachable enough", "too inflexible", etc. are > perfectly valid reasons to reject a syntax. "Looks like <insert language > here>" is not, I content, one of them.
I believe it should be pretty clear that "too perlish" means "too cryptic and makes no sense because it duplicates already implemented functionality (more than one way to do it, yeah)". But "too perlish" is much shorter.
-- Wbr, Antony Dovgal

Alexey Zakhlestin

18 years ago
I hardly find it too cryptic (it makes some array algorythms much more readable, actually) and in this case, having such construction would allow us to implement array_slice() in userland (which is not true other way round) ;) On 10/6/07, Antony Dovgal <tony@daylessday.org> wrote:
> On 06.10.2007 22:38, Larry Garfield wrote: > > I have no love for Perl (and a rather strong dislike of it), but I have to > > agree with those who say that "looks like Perl" is a lame reason to reject > > something. PHP's object system looks an awful lot like Java, too. That > > doesn't make it bad. > > > > "Too unreadable", "not approachable enough", "too inflexible", etc. are > > perfectly valid reasons to reject a syntax. "Looks like <insert language > > here>" is not, I content, one of them. > > I believe it should be pretty clear that "too perlish" means "too cryptic > and makes no sense because it duplicates already implemented functionality > (more than one way to do it, yeah)". > > But "too perlish" is much shorter. > > -- > Wbr, > Antony Dovgal > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Antony Dovgal

18 years ago
On 06.10.2007 23:57, Alexey Zakhlestin wrote:
> I hardly find it too cryptic (it makes some array algorythms much more > readable, actually)
Good for you.
> and in this case, having such construction would allow us to implement > array_slice() in userland (which is not true other way round) ;)
I don't get your problem, sorry.
-- Wbr, Antony Dovgal

Emil Hernvall

18 years ago
On a related note. Code like: $foo = array("a" => range(1,10), "b" => range(11,20)); print_r($foo[][0]); results in Fatal error: Cannot use [] for reading in Command line code on line 3 It would be incredibly useful when handling regular two-dimensional database-resultsets. Essentially, what I'm after is things like this: $result = $pdo->fetchAll(PDO::FETCH_ASSOC); $result = array_combine(result[]['my_id'], $result); If I prepared a patch that made this possible, would it be considered for inclusion? Is there any issues I've overlooked or other objections?

Andrei Zmievski

18 years ago
I will use an example: $foo = substr($bar, 0, 5) . "-" . substr($bar, 5); or $foo = $bar[:5] . "-" . $bar[5:]; I would argue that the second line is hardly more cryptic than the first one. And if we were concerned that concerned about duplicate functionality, we probably wouldn't have SimpleXML and similar things. -Andrei http://10fathoms.org/vu - daily photoblog On Oct 6, 2007, at 11:49 AM, Antony Dovgal wrote:

Antony Dovgal

18 years ago
On 09.10.2007 06:32, Andrei Zmievski wrote:
> I will use an example: > > $foo = substr($bar, 0, 5) . "-" . substr($bar, 5); > > or > > $foo = $bar[:5] . "-" . $bar[5:]; > > I would argue that the second line is hardly more cryptic than the > first one.
How come? It looks like you're reading $bar[':5'], but forgot the quotes. On the other side, what could be easier than a function call?
> And if we were concerned that concerned about duplicate > functionality, we probably wouldn't have SimpleXML and similar things.
Mistakes done in the past do not mean we should continue to do them in the future.
-- Wbr, Antony Dovgal

Alexey Zakhlestin

18 years ago
On 10/9/07, Antony Dovgal <tony@daylessday.org> wrote: > On 09.10.2007 06:32, Andrei Zmievski wrote: > > I will use an example: > > > > $foo = substr($bar, 0, 5) . "-" . substr($bar, 5); > > > > or > > > > $foo = $bar[:5] . "-" . $bar[5:]; > > > > I would argue that the second line is hardly more cryptic than the > > first one. > > How come? > It looks like you're reading $bar[':5'], but forgot the quotes. > On the other side, what could be easier than a function call? operator is definitely easier because it lets us reuse the same syntax for strings and arrays (and people would need to learn one operator instead of 2 functions and 2 different concatenation operators) > > > And if we were concerned that concerned about duplicate > > functionality, we probably wouldn't have SimpleXML and similar things. > > Mistakes done in the past do not mean we should continue to do them in the future. simplexml is a mistake? :-/ then DOM is, probably, a mistake too… (it can be implemented in userland using SAX functions) I always thought, that simplexml was the reason xml became "fun" in php (and that was the reason which made a lot xml-programmers upgrade to php5) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Marcus Börger

18 years ago
Hello Antony, Saturday, October 6, 2007, 8:49:14 PM, you wrote:
> On 06.10.2007 22:38, Larry Garfield wrote: >> I have no love for Perl (and a rather strong dislike of it), but I have to >> agree with those who say that "looks like Perl" is a lame reason to reject >> something. PHP's object system looks an awful lot like Java, too. That >> doesn't make it bad. >> >> "Too unreadable", "not approachable enough", "too inflexible", etc. are >> perfectly valid reasons to reject a syntax. "Looks like <insert language >> here>" is not, I content, one of them.
> I believe it should be pretty clear that "too perlish" means "too cryptic > and makes no sense because it duplicates already implemented functionality > (more than one way to do it, yeah)".
> But "too perlish" is much shorter.
Right, it is a term we somehow agreed on without ever saying so. Best regards, Marcus

Andrei Zmievski

18 years ago
So what? Just because other languages implemented a good idea first does not mean that it is verboten to us. PHP is result of years of evolution (and yes, Terry, it's also a ball of nails) and stealing ideas is one way to inject fresh genes into it. -Andrei On Oct 6, 2007, at 11:09 AM, Marcus Boerger wrote: