rotem@svn.wikimedia.org wrote:
Reverting the addition of class names near the parameters: it doesn't seem to have a purpose, and breaks PHP 5.0.4 on my computer (PHP raises error when the parameters are set to null).
For reference, as of PHP 5 you can specify type requirements on function parameters, to enforce that objects of the correct type are passed. Unfortunately this is pretty limited; you can't allow 'type-X-or-null' or other such conditions, nor I think can you specify non-object types.
Of course it's a runtime check, not compile-time, so probably doesn't tell you anything that you wouldn't get from the fatal error trying to call a nonexistent method. ;).
[I often wish that you *could* enforce type-X-and-not-null in languages like Java at compile-time, though...]
http://www.php.net/manual/en/language.oop5.typehinting.php
-- brion vibber (brion @ pobox.com)
-----Original Message----- From: wikitech-l-bounces@wikimedia.org [mailto:wikitech-l-bounces@wikimedia.org] On Behalf Of Brion Vibber Sent: 22 November 2006 22:51 To: wikitech-l@wikimedia.org Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [17833]trunk/phase3/includes/Linker.php
rotem@svn.wikimedia.org wrote:
Reverting the addition of class names near the parameters: it doesn't seem to have a purpose, and breaks PHP 5.0.4 on my computer (PHP raises error when the parameters
are set to
null).
For reference, as of PHP 5 you can specify type requirements on function parameters, to enforce that objects of the correct type are passed. Unfortunately this is pretty limited; you can't allow 'type-X-or-null' or other such conditions, nor I think can you specify non-object types.
Setting the default for typed parameter to be null, allows type-X-or-null
class Foo { } class Bar { }
function f(Foo $foo = null) { var_dump($foo); }
f(new Foo()); f(); f(null);
f(new Bar()); // Catchable fatal error
Though can't remember which version this was added, and if your refering to something older.
Jared
On 11/23/06, Jared Williams jared.williams1@ntlworld.com wrote:
-----Original Message----- From: wikitech-l-bounces@wikimedia.org [mailto:wikitech-l-bounces@wikimedia.org] On Behalf Of Brion Vibber Sent: 22 November 2006 22:51 To: wikitech-l@wikimedia.org Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [17833]trunk/phase3/includes/Linker.php
rotem@svn.wikimedia.org wrote:
Reverting the addition of class names near the parameters: it doesn't seem to have a purpose, and breaks PHP 5.0.4 on my computer (PHP raises error when the parameters
are set to
null).
For reference, as of PHP 5 you can specify type requirements on function parameters, to enforce that objects of the correct type are passed. Unfortunately this is pretty limited; you can't allow 'type-X-or-null' or other such conditions, nor I think can you specify non-object types.
Setting the default for typed parameter to be null, allows type-X-or-null
class Foo { } class Bar { } function f(Foo $foo = null) { var_dump($foo); } f(new Foo()); f(); f(null); f(new Bar()); // Catchable fatal errorThough can't remember which version this was added, and if your refering to something older.
Someone mentioned that as a comment in the PHP docs, but I suspect it may have been added after 5.0 proper, since Rotem reported problems with 5.0.4. We haven't introduced any dependencies for after 5.0; otherwise I would have started type-hinting arrays too, which was added in 5.1. So for now I'll be cautious when adding these.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical wrote:
Setting the default for typed parameter to be null, allows type-X-or-null
[snip]
Someone mentioned that as a comment in the PHP docs, but I suspect it may have been added after 5.0 proper, since Rotem reported problems with 5.0.4. We haven't introduced any dependencies for after 5.0; otherwise I would have started type-hinting arrays too, which was added in 5.1. So for now I'll be cautious when adding these.
Confirmed that this doesn't work in 5.0.4 (throws fatal error for null), does work in 5.1.4.
There's still a lot of 5.0.x installations out there, though I'd love to see them all die -- in addition to the security problems (probably left unfixed since the currently maintained 5.x has continued on to 5.1.x, and now 5.2.x) there's the array index corruption on 64-bit machines, which is now fatal due to breakage of the namespace arrays.
For 1.9 and 1.8.3 I've introduced a check for the array index corruption on install, with a recommendation to upgrade to 5.1 or later for affected machines.
- -- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org