[PATCH] Making in_array a language operator

13 years ago by Antoine Delignat-Lavaud — view source

unread

Hello,

While browsing through the changelog for PHP 5.4, I noticed the new
short syntax for creating arrays. I had been wanting this feature for a
very long time, and this pushed me to make a proposal for a similar
syntax change to make PHP more elegant.

My proposal is simply to add an infix operator version of in_array. One
of the main goals is to avoid statements such as:

if(($v1=="a1" || $v=="a2" || ...) && ($v2=="b1" || $v2=="b2" ||...) && ...)

by replacing them with:

if($v1 in ["a1","a2",...] && $v2 in ["b1","b2",...])

To back up my proposal I have made a patch that implements this
operator. It is quite straightforward for the most part, but there are a
few design decisions to validate, including the behavior when the
operator is used on a non-array (I suppose it might be possible to
extend it to objects but the usefulness of this seems questionable), and
whether to use strict or loose equality by default (I chose the later).

There are actually two versions of the patch, one that will change the
internal pointer of the array to either the first matching element or
the last if none matches, the other leaving the internal pointer
unchanged. Although I prefer the first solution because it can emulate
array_search using key() without resorting to ===FALSE, I reckon this
kind of behavior is depreciated since PHP 4, hence the "pointersafe"
version. If you want to try this patch remember to regenerate your
zend_vm_execute.h and zend_vm_opcodes.h by running zend_vm_gen.php.

Although I am well aware that the core language should never be changed
thoughtlessly and that PHP generally dislikes most kinds of syntactic
sugar (it's not Perl, alright), I hope you will still consider this
proposal for a future version of PHP.

With Regards,

Antoine Delignat-Lavaud

13 years ago by johannes@schlueters.de — view source

unread

Hi,

if(($v1=="a1" || $v=="a2" || ...) && ($v2=="b1" || $v2=="b2" ||...)
&& ...)

This could also be written as
if (in_array($v1, ["a1", "a2", ...]) && in_array($v2m ["b1", "b2", ...]))

by replacing them with:

if($v1 in ["a1","a2",...] && $v2 in ["b1","b2",...])

I would certainly not add it to 5.4.

For 5.5 I also have doubts whether it's worth the additional keyword and
opcode. Yes it will, most likely, but this is an extension to the
grammar ...

johannes

13 years ago by johannes@schlueters.de — view source

unread

For 5.5 I also have doubts whether it's worth the additional keyword and
opcode. Yes it will, most likely, but this is an extension to the
grammar ...

I meanwhile did a quick check on google codesearch. I found a few cases
where "in" was used as property or method name. Notable cases there are
zeta components and doctrine2 which this patch would break.

Two more comments I wanted to make:

Your using is_equal_function, this does a == comparison. People will
stumble over $a = 0; $a in ["a", "b", "c", "it's easy as one two
three"]; which will be true. This is the consistent and correct
behaviour for the language but people will ask for a "strict" mode.

For converting functions into opcodes - aren't there more relevant
candidates? strlen() or such come to mind. And no, I won't make them
constructs either.

johannes

13 years ago by Pierre Joye — view source

unread

2011/11/13 Johannes Schlüter johannes@schlueters.de:

For 5.5 I also have doubts whether it's worth the additional keyword and
opcode. Yes it will, most likely, but this is an extension to the
grammar ...

I meanwhile did a quick check on google codesearch. I found a few cases
where "in" was used as property or method name. Notable cases there are
zeta components and doctrine2 which this patch would break.

Right, that would be a BC break for method names. Properties work just
fine (and now already with for, while &co if you try).

For converting functions into opcodes - aren't there more relevant
candidates? strlen() or such come to mind. And no, I won't make them
constructs either.

There is an idea to have pseudo object for common types, where these
functions would be callable without actually having an instance. No
implementation yet so far.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Pierre Joye — view source

unread

2011/11/13 Antoine Delignat-Lavaud antoine.delignat-lavaud@ens-cachan.fr:

please use two replies next time :)

There is an idea to have pseudo object for common types, where these
functions would be callable without actually having an instance. No
implementation yet so far.

So this means being able to use $string->strlen() (or even $string->len())
instead of strlen($string) or $array->in_array($x) ($array->in($x)) instead
of in_array($x,$array), right?

Yes, that's the idea, but then with obvious names:

$string->length(); or $string->length;
$array->in($x);

instead of reusing the horrible string functions we have right now
(needle haystack orders and other (impossible to remember) funny
things ;).

That seems like a step in the right direction, with no change to the syntax
required. I'll try to see if I can make an implementation of this but I fear
it might be a bit more complex than just new language constructors.

It is definitively more tricky yes.

Cheers.

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Martin Jansen — view source

unread

2011/11/13 Antoine Delignat-Lavaud antoine.delignat-lavaud@ens-cachan.fr:

There is an idea to have pseudo object for common types, where these
functions would be callable without actually having an instance. No
implementation yet so far.

So this means being able to use $string->strlen() (or even $string->len())
instead of strlen($string) or $array->in_array($x) ($array->in($x)) instead
of in_array($x,$array), right?

Yes, that's the idea, but then with obvious names:

$string->length(); or $string->length;
$array->in($x);

That last one doesn't sound right. Didn't you mean $x->in($array)? Or at
least $array->contains($x)?

Martin

13 years ago by Rasmus Lerdorf — view source

unread

2011/11/13 Antoine Delignat-Lavaud antoine.delignat-lavaud@ens-cachan.fr:

So this means being able to use $string->strlen() (or even $string->len())
instead of strlen($string) or $array->in_array($x) ($array->in($x)) instead
of in_array($x,$array), right?

Yes, that's the idea, but then with obvious names:

$string->length(); or $string->length;
$array->in($x);

instead of reusing the horrible string functions we have right now
(needle haystack orders and other (impossible to remember) funny
things ;).

That seems like a step in the right direction, with no change to the syntax
required. I'll try to see if I can make an implementation of this but I fear
it might be a bit more complex than just new language constructors.

It could also easily be a step in the wrong direction if it isn't
implemented carefully. Turning interchangeable scalar types into fake
objects could introduce the equivalent of strong typing.

Doing: $a=12; echo strlen($a); and getting 2 shouldn't suddenly break if
you do it using $a->length() which means all scalar fake object methods
would be available on all scalar objects regardless of their type.
Otherwise it is just a sneaky way of introducing strict typing and that
would cause a lot of pain for a lot of people.

And while I know I floated the idea myself a while back, I'm not a fan
of scalar objects at all. It's not like it cleans up the global
namespace any, and given the requirement to maintain interchangeable
basic scalar types it doesn't even provide clean per-scalar namespaces
since all the methods would have to be in one.

-Rasmus

13 years ago by Pierre Joye — view source

unread

It could also easily be a step in the wrong direction if it isn't
implemented carefully. Turning interchangeable scalar types into fake
objects could introduce the equivalent of strong typing.

Indeed, that's not an easy thing to think about or design. Many cases
to clearly document or implement.

Doing: $a=12; echo strlen($a); and getting 2 shouldn't suddenly break if
you do it using $a->length() which means all scalar fake object methods
would be available on all scalar objects regardless of their type.
Otherwise it is just a sneaky way of introducing strict typing and that
would cause a lot of pain for a lot of people.

And while I know I floated the idea myself a while back, I'm not a fan
of scalar objects at all. It's not like it cleans up the global
namespace any, and given the requirement to maintain interchangeable
basic scalar types it doesn't even provide clean per-scalar namespaces
since all the methods would have to be in one.

They don't or shouldn't be object per se, it would be too slow
somehow. It won't cleanup the global namespace as there will have no
gain to drop the other functions, even if they are inconsistent.

However that's definitively something I would like to have, as it
makes the code cleaner and allows me to stop to have to rtfm for every
2nd scalar related function. But again, it is not a small task nor
easy, may never happen as well :)

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org