RE: [PHP4BETA] A quick clarification question about PHP4...
| From: | Zeev Suraski | Date: | Tue, 24 Aug 1999 20:43:01 +0000 |
| Subject: | RE: [PHP4BETA] A quick clarification question about PHP4... | ||
| References: | 1 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-3689@lists.php.net to get a copy of this message | ||
At 17:39 24/08/99 , Samuel Liddicott wrote:
-----Original Message----- From: Zeev Suraski [mailto:zeev@zend.com] Sent: 24 August 1999 05:04 PM To: Samuel Liddicott; Jim Brain; Andi Gutmans; Zend Subject: RE: [PHP4BETA] A quick clarification question about PHP4... At 16:54 24/08/99 , Samuel Liddicott wrote:I think it isn't at all, on the contrary. As a matter of fact, if there's one thing I'm truly sorry for, it's introducing the 'var' construct. It was introduced in PHP 3.0 before we had the ability to implement constructors - otherwise we wouldn't have that thing at all in the language. Mind you, you don't have to declare it at all, you can just initialize it in the constructor. The 'var' construct pretty much goes against the nature of PHP by explicitly declaring variables before using them, and should be obsolete and replaced by constructors: class thingy { function thingy() {is clear to humans but we are now forced to arrange it differently. The annoying thing is that this is the kind of thing machines aregood at! Theparser should recognize the type of things it is can'tinitialize statically(or how will it report an error) and then initialize by code itin a secrethidden pre-construtor.Uhh no, you're not forced to arrange it differently at all - $this->foo = $bar is an expression, just like $foo = $bar. It's not static initialization, it's not member variable initialization, it's nothing. I know. The re-arrangement is from: class thingy { var $field=GetRandomName(); } to: class thingy { var $field; function thingy() {$field=GetRandomName();} } And whatever C++ does or doesn't do, writing: class thingy { var $field=GetRandomName(); } is amazingly shorter and clearer.
$field=GetRandomName();} }
The same for: function x($a=$b[0],$c=$d[0]) { which must now be written as: function x($a) { if (!isset($a)) {$a=$b[0];} [Although I think you sed that this was a parser problem with no workaround]We rarely have parser problems now, we can pretty much parse anything we want. Parsing is a non issue really, it's code generation and data structures that make implementing this very complex in a compile&execute model. I truly think this is not a big deal. I also think that it pretty much never makes sense to use dynamic expressions in static initializers or in default argument values. In the few cases it does, it's easy enough to use the standard tools PHP gives you to implement your code properly.
It really has little to do with C++. It has to do with a compile&executeIt's not the C++ model, it's a typical compile&execute model.model, vs. an interpreter model. The compile&execute model ismuch, much better. In that case why stick to the C++ model of static initializers?
When you compile: var $field=GetRandomName(); stick it in a hidden pre-constructor or a post-memory-allocator or something so it gets compiled, and then executed in the right place. Developer gets clear flexible code, php compiles it and then executes it.This is one of the cases (and as I said earlier, the most uninteresting case IMO). Static initializers and function arguments are more complicated. We might do that, but not in the near future. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il