PHP Syntax - how would you change it?

The poll on the main sitepoint page at current asks the user what they would like to do to rename the JavaScript ‘function’ keyword.

So, that make me think - what would you do to change PHP’s syntax?

Of course the characters must be available on the typical keyboard, so signs like the british pound £ and the euro aren’t viable.

I’d get rid of ‘$this->’ and ‘self::’ in object-oriented programming. I cannot stand it. I think methods and properties should be accessed like #method() and #property rather than $this->method() and $this->property (# is a comment operator, but it is rarely used compared to double-slashes //). I also think static functions and variables should be accessed with a double-colon alone, e.g. ::function() and :: property. (without the space; :: + p = ::stuck_out_tongue: in vbulletin ;))

This would also apply in the declarations. I think the function keyword is unnecessary because the parser could tell whether it was a property or method.

I’d also allow multiple function declarations under the same function name but using different parameters. That would save quite a lot of framework-development pain!

I’d also allow arrays with the square braces, rather than the array function.

So ideally:

class Someclass{
    #variable = 'hello';
    #func(array $var){
        printf($var);
    }
    #func($var1, $var2){
        #func(['one' => $var1, 'two' => $var2]);
    }
    #__Construct(){
        #func(#variable, 'world');
    }
}

It looks a little confusing and the forum PHP highlighting certainly won’t help so I left it as plain code.

I’d find it necessary to have a distinction between global functions and object methods, because otherwise you wouldn’t be able to access typically-used functions if it is redefined in your class, which is supposedly common.

Of course, that’s just my idea of what I’d do - what would you do?

Off Topic:

Jake, have you looked at the operator PECL extension? It’s a little old now, but might fit in nicely with an everything-as-object approach to overloading.

Actually, code converting applications would be very simple to write, so changing legacy code isn’t that difficult.

However, if you’re going to upgrade your PHP major version, you should really be changing your code too. PHP4 code is better suited on a PHP 4 server, etc. I’m talking about future developments.

I stick to my belief that a ‘fork’ of PHP should be started; it is open-source after all. Maybe call it PHPi? This would involve above suggestions such as a completely rewritten library, scalars existing as objects, a better concatenation operator (I’d prefer the same as with numbers - “hello” + “world”) and a different object operator (remember that -> isn’t as easy on some keyboards as it is with standard US/UK) I’d also like ‘infix’ methods (Or as I’m familiar with them, operator overloaders).

That way it doesn’t interfere with most programmers who want PHP to stay the same, but offers a platform more satisfying for those who wish for something different.

Nothing, wouldn’t want to upset almost 10 years of muscle memory.

Changing -> to something else could only happen at a full version, say 7 to make it easy for libraries etc. As Go says, realistically though there would have to be some other pretty impressive changes for Businesses to choose to rewrite all their legacy code.

Why change anything? I mean, nothing is so bad we can’t get along with it. I don’t think it would help much anyway. For example changing -> to . notation may seem like a great idea, but what about all the reusable code libraries we’ve been building up, would we have to change all of that too? Or would we end up still using -> to keep our code-bases consistent?

Rather than trying to make PHP like other langauges, why not just embrace its PHPnes.

That’s it what I would like to see changed at first hand :smiley:

Apart from that, there might be lots of things to be ‘would be better…’ not essentially :wink:

Good point, you got me there :slight_smile:

Only problem with that is, you’re back with “on some hosts X, on other hosts Y”. Not that I have anything better to offer, save for just abandoning any hope of backwards compatibility.

I suppose this is the core problem with PHP, it was originally designed as a kind of templating system for C libraries, and in that particular context, it does a really good job of it.

As an actual language, it’s horrible, but as a templating system, it’s wonderful! so wonderful in fact, that people wanted to use it for everything, and thats how it came to be the awful mess it is today.

I like this idea!

Especially if there were a set of standard modules that you could rely on.

One of the disadvantages of being embedded into the web server is that you sort of pull all these libraries along for the ride, having dozens of libraries linked into PHP is a serious liability, but, unless it’s a separate process, I can’t really see a good way around it.

Call me silly, but I actually like much of what perl’s DBI has. DSN’s are kind of “weird”, but they do allow much greater flexibility in other parts of the code, for vanilla SQL stuff, you don’t have to care which database it is.

I also really like placeholders, they can dramatically decrease SQL injection bugs… but thats more of a “what I hate about mysql” essay… another wonderful tool that was expanded well beyond what it had originally set out to do.

There was once a time, when I thought “lpr <file.mp3” would be a neat thing to do. After seeing what happened with these templating systems and tiny simple databases… I now see the error of my thinking.

Best thing on that page:

PHP’s coding style pulls common elements from C++, Java, PERL, Python, BASIC, Assembly, Dragonspeak, and Microsoft Office Excel.

:smiley:

Heh heh… Extensions are great. Extensions you don’t need are indeed bad.

Again, I’d like to see the existing functionality cordoned off into a legacy namespace. By default it would be included into the project but you can turn it off in PHP.ini, or in the apache .htaccess or .httpd.config directive files.

If you turn off the legacy namespace you are left with the core namespace which is only the essential functions. Database connectivity would require importing the namespace of the DB you are actually going to use into your project.

I would imagine that this would help the interpreter parse the scripts faster since the number of functions and constants to consider during pattern matches would be considerably reduced.

$a = 0 ?: 0 ?: 'A';

Wait so inbuilt database connectivity is bad?

Extensions are bad?

And no doubt, some hosts have done this, other hosts haven’t.

When a hosting provider says they “have php” it’s really quite meaningless, their PHP is very likely not the same PHP as yours or the guys next door.

Hence the 200+ lines of code you see in php applications that test for this…

For kicks (and saddly, true in some respects!):
http://uncyclopedia.wikia.com/wiki/PHP

There should really only be a handful of functions, things like “array” are redundant.

I think what geniegate meant is:


$a = 0 || 'A';
var_dump($a); // output: bool (true)

While he would want it to output string(1) “A”, like javascript does.


var a = 0 || 'A';
alert(a); // alerts 'A'

:slight_smile:

Actually ‘A’ is TRUE. It evaluates to a non-empty value.

When converting to  [boolean](http://www.php.net/manual/en/language.types.boolean.php) , the following values are  considered    [B]FALSE[/B]:   

I’d GET RID OF ALL THESE BUILT IN FUNCTIONS

For example, mysql_ would go bye-bye, as would 90% of the other functions.
Disable or remove the MySQL Extension. That is where the mysql_* functions reside. Along with most others.

Very interesting! Thanks again. :wink:

oh, that reminds me: infix functions!


infix function add($a, $b) {
return $a + $b;
}

echo 1 add 2; //prints 3.

Consider this:


class MyClass {
  public $total;
}

$obj1 = new MyClass;
$obj1->total = 1;

$obj2 = new MyClass;
$obj2->total = 2;

infix function +(MyClass $a, MyClass $b) {
 return $a->total + $b->total;
}

echo $obj1 + $obj2;

Of course you’d also need method overloading for it to work really well.

One of my favourite things about Eiffel :slight_smile:

$v = 0 || 0 || ‘A’;

$v would contain ‘A’. (not TRUE)

I’d add unless(){ … }

if(! blah) { } // <— this stinks.

I’d add post-conditionals and get rid of single line conditionals.

if(true)
do_something(); // <– this stinks

do_something() if(true); // <– this is more readable for 1 liners.

inline, LEXICALLY SCOPED finctions.

function bark(){
$a = “Apple”;
$accum = array(A => ‘’);
$ptr = &$accum[‘A’]; // or \$accum[‘A’] I don’t care… long as $ptr works
$v = function(){
print $a;
*$ptr .= “Appended”;
}
$v->() // prints “Apple”
print $accum[‘A’]; // Now contains “Appended”
}

Sane, predictable reference handling with lexically scoped functions is extremely useful for callback stuff, like parsing XML. True, it’s easy to hang yourself, but it’s a lot easier than trying to keep track of the hash index you were using (plus it ought to be faster, only need the hash lookup once)

On the subject of references… everything would be passed by reference, all the time. If you want a copy, you have to explicitly do that. (maybe php5 has this, I don’t know… often, when I’ve tried to use php’s references I get segfaults)

I’d GET RID OF ALL THESE BUILT IN FUNCTIONS

For example, mysql_ would go bye-bye, as would 90% of the other functions.

I’d get rid of $_GET, $_POST and friends, replace with some sort of Request() object that allowed you to specify things (like whether you want \’ escaped each time or if you like using ; to separate variables) at the time of construction, instead of just having them “appear”. No more foo.php?v[A]=bark unless you want this. (indeed, who says input is always urlencoded?)

Some sort of super-static area, I realize the archetecture doesn’t support it, but in some cases, like with other languages and FastCGI or Servlets, it’s nice to create an object and re-use it for multiple requests.

And my #1 PHP peeve: BYE-BYE HOST QUIRKS!!!

No more “compile time disabled” crap, nor host-centric “settings”. If a function is in the docs, you should be able to rely on it always working. No more having to:

if(this_wacky_host_has_blah_set()) { … work around quack host … }

PHP should work the same, on all hosts, with very, very few exceptions. When the first 200 lines of your program are tests to work around different “configurations”, something is seriously wrong.

I want an standard installation pr. user, some place a web application can store code, settings and data. OUTSIDE OF WEB SPACE.

Sort of like WEB-INF/

There should be some mechanism for users to adjust ini files in WEB-INF/conf Ideally with a template, so when you write an installer, you can query for something that is likely to be their mysql/postgresql/website/blah settings and present it to them as defaults.

It should be possible to install libraries in this directory w/out a huge hassle.

Most of all, I don’t want stuff being placed in the document root unless it’s explicitly there for web browsers to access.

… and probably lots more things …

Then why not $myobj = (object) array(‘x’ => 4, ‘y’ => 2); ?