substr/array_slice in []

17 years ago by Ilia Alshanetsky — view source

unread

This was not on the table and the time of the 5.3 discussion, I for
one think its a bit too much magic.

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 Alshanetsky

17 years ago by Antony Dovgal — view source

unread

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

17 years ago by Jeff Griffiths — view source

unread

Antony Dovgal 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

17 years ago by Cristian Rodriguez — view source

unread

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/

17 years ago by Stanislav Malyshev — view source

unread

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

17 years ago by Andrei Zmievski — view source

unread

It's on my TODO list.

-Andrei

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)?

17 years ago by Martin Alterisio — view source

unread

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:

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/

17 years ago by Stanislav Malyshev — view source

unread

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

17 years ago by Alexey Zakhlestin — view source

unread

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/

17 years ago by Martin Alterisio — view source

unread

2007/10/2, Alexey Zakhlestin indeyets@gmail.com:

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.

17 years ago by Larry Garfield — view source

unread

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

17 years ago by Alexey Zakhlestin — view source

unread

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/

17 years ago by Derick Rethans — view source

unread

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

17 years ago by Marcus Boerger — view source

unread

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:

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

17 years ago by Larry Garfield — view source

unread

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.

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:

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

17 years ago by Antony Dovgal — view source

unread

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

17 years ago by Alexey Zakhlestin — view source

unread

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) ;)

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
http://blog.milkfarmsoft.com/

17 years ago by Antony Dovgal — view source

unread

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

17 years ago by Emil Hernvall — view source

unread

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?

17 years ago by Rasmus Lerdorf — view source

unread

Emil Hernvall wrote:

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?

Yes, I object on the basis that I have no idea what that syntax should
do by looking at it. The auto-incrementing [] array syntax has always
been a write-only construct. Auto-incrementing on a read doesn't make
any sense which means you are overloading that syntax to mean something
completely different.

-Rasmus

17 years ago by Antony Dovgal — view source

unread

$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?

Yes, I object on the basis that I have no idea what that syntax should
do by looking at it. The auto-incrementing [] array syntax has always
been a write-only construct. Auto-incrementing on a read doesn't make
any sense which means you are overloading that syntax to mean something
completely different.

This syntax makes no sense in write context to me either.
-1

--
Wbr,
Antony Dovgal

17 years ago by Andrei Zmievski — view source

unread

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

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

17 years ago by Antony Dovgal — view source

unread

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

17 years ago by Alexey Zakhlestin — view source

unread

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/

17 years ago by Antony Dovgal — view source

unread

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)

Yes, I see this quite often in the list: "let's invent a new thing instead
of an old thing, that would make peoples' life easier".

But you forget that both the old and the new thing would co-exist
and people would have to learn BOTH, which definitely doesn't make any life easier.

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? :-/

No, I don't think SimpleXML in particular is a mistake, but encouraging people
to do mistakes just because they've done it in the past is quite.. unreasonable.

That said, why are we still discussing this?
From what I understood, most of the core developers agreed that there are no
reasons to implement this syntax, so we're just wasting our time and traffic here.

--
Wbr,
Antony Dovgal

17 years ago by Andrei Zmievski — view source

unread

Most of the core developers were present at the PDM in Paris where that
item was put on the list.

-Andrei

Antony Dovgal wrote:

From what I understood, most of the core developers agreed that there are no
reasons to implement this syntax, so we're just wasting our time and traffic here.

17 years ago by Stanislav Malyshev — view source

unread

operator is definitely easier because it lets us reuse the same syntax
for strings and arrays (and people would need to learn one operator

Having same syntax mean two different things (string access / array
access) doesn't qualify as "easy" in my book anyway. I know there's a
language which uses only 8 characters for everything (since this is a
family-oriented mailing list, I'm not going to mention it by name ;) -
but it is hardly easy.
I would be kind of OK if we made substring operator be {X:Y}, but for
array operator I don't really see how it's substantially better than
calling array_splice. It has a bit less characters to type, but less
typing is not always better. It also doesn't make sense in a lot of
array contexts (what is $a["apples":"oranges"]?) so it doesn't extend
old [] syntax naturally.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Marcus Boerger — view source

unread

Hello Antony,

Saturday, October 6, 2007, 8:49:14 PM, you 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

17 years ago by Andrei Zmievski — view source

unread

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

However I agree that this kind of slicing is a bit too perlish or
pythonish.

substr/array_slice in []

I think since we do have substr/array_slice there's no need to overload [] operator.

I think since we do have substr/array_slice there's no need to overload
[] operator.