All the Perl that's Practical to Extract and Report

Another reason I hate PHP

petdance on 2004-01-06T20:41:19

In Perl, if you split an empty string, you get back zero elements: my @foo = split( ":", "" ); print Dumper( \@foo ); # $VAR1 = []; In PHP, if you split an empty string, you get back a one-element array with 0 as the key and an empty string for the value. $foo = explode( ":", $str ); print_r( $foo ); $foo = split( ":", $str ); print_r( $foo ); $foo = preg_split( "/:/", $str ); print_r( $foo ); ... in all three cases prints Array ( [0] => ) This of course means that I must explicitly check to see if the value on my first element is blank, or must myself check to see if the string I'm splitting is blank.

frickin' frackin' grambl-grrrrr...

Why?

shiflett on 2004-01-06T21:28:32

I don't really see why this is bad (feel free to show me the errors of my ways, heh). Why should whether PHP behaves like Perl have any bearing on its merits as a language? I'm always happy to listen to the arguments against PHP, and there are some good ones, but this seems a bit trivial to me.

In addition, PHP's implementation makes more sense in this case, especially since it is consistent with other PHP functions. If explode() returns an array, I can be confident that I always get an array, and the elements in the array are the pieces of my original string, regardless of what the string may have been. I'd rather a language not try to guess my intentions or decide that I would like my empty string converted to an empty array.

$string = 'foo:bar';
$foo = explode(':', $string);
$bar = explode(',', $string);

print_r($foo);
print_r($bar);

In this case, both $foo and $bar are arrays, even though a comma does not exist in the string. This outputs:

Array
(
    [0] => foo
    [1] => bar
)
Array
(
    [0] => foo:bar
)

It makes sense to me that $bar is an array with a single element, [0] => foo:bar. For the same reason, it makes sense to me why using explode() on the empty string would do the same.

Re:Why?

petdance on 2004-01-06T21:47:19

An empty array is still an array, so why not allow that?

Here's what I was doing. I had a string of codes that looked like this: "2 4 7". So I expected to be able to do:

$codes = split( " ", $str );
foreach ( $codes as $code ) {
    print $lookup[$code];
}
However, if $str is empty, instead of going thru the loop zero times, which is what I would expect, I go through once and now have an error because "" is not in my $lookup array. Instead, I have to do this:
if ( !empty($str) ) {
    $codes = split( " ", $str );
    foreach ( $codes as $code ) {
        print $lookup[$code];
    }
}
Zero/empty is a perfectly valid construct. explode() et all should support it.

Re:Why?

shiflett on 2004-01-06T22:34:11

Your example makes a lot more sense, and I think I understand your complaint better now. :-)

I guess that I've never encountered this type of situation, because I am usually dealing with data that originates from the user. As such, I would be checking what's in $str (or checking each element in $codes) to make sure that it's a valid key for $lookup.

You might prefer to do this:

$codes = explode(' ', $str);
foreach ($codes as $code)
{
     @echo $lookup[$code];
}

The @ will suppress errors, since you're not concerned with whether $code is a valid key for $lookup in this case.

It's like grep, but not

broquaint on 2004-01-07T15:47:10

It's a simple matter of using PHP's wonderful approximation of grep ...
foreach( array_filter(explode(",", ""), create_function('$a','return !empty($a);')) as $v ) {
  echo "got: $v\n";
}
Or not ...

Re:Why?

runrig on 2004-01-06T21:52:04

In addition, PHP's implementation makes more sense in this case

In practice, I've found perl's behavior in this regard convienient. If for some reason I want PHP-like behavior, I can always add a one liner after the split:

@array = ('') unless @array;

Re:Why?

runrig on 2004-01-06T21:53:44

...and my resolution for this year is to learn to spell convenient.

Re:Why?

jordan on 2004-01-06T23:49:31

  • I'm always happy to listen to the arguments against PHP...

And, I'm willing to listen to arguments for PHP. What does PHP buy you that you can't get with things like plp or the various templating systems?

I've never done any PHP myself, but those I know who have used it are constantly frustrated by the limitations and often resort to Perl on the backend. Why have two languages? The maintenance and support nightmares multiply in that kind of environment, from what I can see.

Maybe PHP had a place once upon a time, but with mod_perl so mature now, that time seems gone to me.

But, like I said, I've never done any PHP, enlighten me!

Re:Why?

shiflett on 2004-01-07T00:34:12

I'm not one to ever argue for PHP over mod_perl or the other way around. To me, both are winners, and you should go with what you're familiar with. My arguments against languages involve all of the stuff that begins with J and all of the stuff made by Microsoft. :-)

Here are some reasons why PHP is so popular (mod_perl shares some but not all of these features):

  1. It's an open source, server-side scripting language made for creating Web applications.
  2. The syntax is very similar to C, so for many programmers, there is practically no time required to learn the syntax.
  3. It is extremely easy to learn. Because you can embed it in HTML, you can start with something as simple as <? phpinfo(); ?> in the middle of some HTML to get started.
  4. It's Web server and OS agnostic, so everyone can try it out regardless of what platform they're running.
  5. It has hooks into just about every Web server and database imaginable.
  6. Because it was designed specifically for the Web, its native features revolve around such needs. Things like session mechanisms are built into the core rather than available as userland modules.
  7. In Apache, it only hooks into the content generation phase, so it's safer to run in multi-user environments. As a result, a large majority of Web hosts offer PHP (combine this with point 3)

You can point to sites like Ticketmaster for mod_perl, and you can point to sites like Yahoo for PHP. Anyone who can't get the job done in either language obviously doesn't know the language very well. :-)

Darn it!

jordan on 2004-01-07T14:03:27

Here I was all set to start a big religious flame war over Perl vs. PHP and you douse it with a cold bucket of reasonableness and solid justification.

Couldn't you at least say something nasty about Perl?

Re:Why?

IlyaM on 2004-01-07T16:01:16

I think the main reason for PHP popularity is that it is the most ISP friendly technology. They have builtin security mechanisms that allow many users to share one server (what is impossible with mod_perl). PHP have so many things builtin what makes it usable platform without installing dozen CPAN modules what somewhat lowers support costs for ISP (no users which request to install module Foo and module Bar). PHP as platform is just cheaper for ISPs to support. Having said this I must admit that after trying to write a couple projects in PHP I hate PHP as language.

perl is right here

jmm on 2004-01-08T16:31:09

The answer perl is giving you seems to be right to me. If you try split( /:/, "a:b::c" ) you get a 4-element result with the third being the null string, ("a", "b", "", "c"). For a single element result, split( /:/, "ab" ) returns the single element "ab", split( /:/, "a" ) returns the single element "a", and split( /:/, "" ) returns the single element "". Returning 0 elements for the last case would be inconsistant with the previous set of results.