PHP Syntax - how would you change it?

[mmj]

Here's what I'd change in PHP if could:



1. Make it mandatory to declare a variable before initialising it kinda like Javascript:

var $newvar = 1;

This will prevent a lot of mistakes that could be hard to debug or lead to security holes.

2. Remove extract(), compact(), register_globals, the global keyword (maybe keep $_GLOBALS).

3. Think about object literals. Ideally they would create new objects of class stdClass or something.

$myobj = object(x => 4, y => 2);

The actual syntax I used is debatable; to emulate Javascript you could use {x:4, y:2} but the above seemed more consistent with other parts of PHP such as array().

PS. I don't like many of the previous suggestions. If there's already a way to do it in PHP then why not leave it as is, for example $this->something is perfectly fine and it's not as if #something saves any actual lines of code (in this instance, I'd say it makes it less intuitive as well).

[Salathe]

If there's already a way to do it in PHP then why not leave it as is

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

[geniegate]

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

[TomB]

oh, that reminds me: infix functions!

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

echo 1 add 2; //prints 3. 

[AnthonySterling]

oh, that reminds me: infix functions!

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

echo 1 add 2; //prints 3. 

What would be the benefit though Tom, just syntactic sugar?

[TomB]

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

[AnthonySterling]

Very interesting! Thanks again.

[logic_earth]

$v = 0 || 0 || 'A';

$v would contain 'A'. (not TRUE)

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

When converting to boolean , the following values are considered FALSE:

• the boolean FALSE itself
• the integer 0 (zero)
• the float 0.0 (zero)
• the empty string, and the string "0"
• an array with zero elements
• an object with zero member variables (PHP 4 only)
• the special type NULL (including unset variables)
• SimpleXML objects created from empty tags

I'd *GET RID OF ALL THESE BUILT IN FUNCTIONS*

For example, mysql_ would go bye-bye, as would 90&#37; of the other functions.

Disable or remove the MySQL Extension. That is where the mysql_* functions reside. Along with most others.

[ScallioXTX]

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

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'

[geniegate]

Disable or remove the MySQL Extension. That is where the mysql_* functions reside. Along with most others.

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.

[TomB]

Wait so inbuilt database connectivity is bad?

Extensions are bad?

[Salathe]

$v = 0 || 0 || 'A';

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

[Michael Morris]

I can certainly see your logic there, but such a change would do more harm than good. The harm is increased complexity. I'm not sure about you, but learning is not fun. If I have to get my hands dirty with a new language, API or environment, it has to be as simple as possible, so I can quickly jump in and get to work. The best languages, frameworks and API's are based on the less is more approach.

Beginning coders have trouble with the concept of datatypes. Expert programmers prefer to use them and avoid loose typing when feasible. There's no clean way around that fact. Hence offer both approaches as I outlined. No one is going to hold a gun to your head and demand you use tolerant or strict vars - and the language would continue working just fine without their use. When you are ready to deal with strict data casting the feature would be there waiting for you. That's hardly in the way and hardly an increase in complexity.

Here's what I'd change in PHP if could:

1. Make it mandatory to declare a variable before initialising it kinda like Javascript:

You don't program Javascript very often do you? It isn't mandatory to declare a variable before using it in javascript. Advised, but hardly mandatory.

The danger of not declaring the variable is largely that of scope. When a variable is referenced the interpreter checks each scope up the chain for the object until it finds the variable or hits the window object. If it hasn't found it when it hits the window object it creates the variable in the local scope and proceeds.

2. Remove extract(), compact(), register_globals, the global keyword (maybe keep $_GLOBALS).

No. Hell no. Register globals is gone in PHP 6 and that is a good thing - along with it say buh bye to safe mode and magic quotes.

Compact is incredibly useful in debugging - so no, removing that is a very stupid suggestion.

Extract is more convenience than necessary, but helps keep code readable. I use it to very powerful effect in my template engine.

The global keyword is necessary as part of function scoping. Yes, it can be misused to create hidden dependencies in a library or framework, and yes it is bad practice to have a function import a var into scope with global and then change it's value rather than return it, but it has it's place in the language.

Just like eval() does for better or worse.

And it's $GLOBALS, not $_GLOBALS.

[Michael Morris]

Wait so inbuilt database connectivity is bad?

Extensions are bad?

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.

[Immerse]

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

Best thing on that page:

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

[geniegate]

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.

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.

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 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.

[mmj]

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

Good point, you got me there

[Raju Gautam]

I wish "->" would be replaced with one character, one that doesn't require the shift key.

That's it what I would like to see changed at first hand

Apart from that, there might be lots of things to be 'would be better...' not essentially

[Salathe]

I wish "->" would be replaced with one character, one that doesn't require the shift key.

Which character would you prefer from (on my keyboard):

1234567890 `-=[];'#\,./
acbdefghijklmnopqrstuvwxyz

[deathshadow60]

While I'm sitting here raging "OH NOES, NOT SHIFT!!!"

[GOPalmer]

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.

[Michael Morris]

That's why one change is a wish and never going to be practical, and the other is something I'd like to see. Changing to dot syntax is never going to be practical.

On the other hand, a legacy namespace arrangement could be installed.

[G3D]

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.

[Jake Arkinstall]

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.

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.

[SpacePhoenix]

Jake, what's your thoughts on the $_REQUEST superglobal, do you think that it should be depreciated and why?