Re: RFC: Making T_FUNCTION optional in method declarations

From: Date: Sun, 28 Nov 2010 21:09:50 +0000
Subject: Re: RFC: Making T_FUNCTION optional in method declarations
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-50673@lists.php.net to get a copy of this message
On Sunday, November 28, 2010 11:24:02 am Dallas Gutauckis wrote: > I understand the concern from above, but I don't agree with it > fundamentally. The kind of practice suggested by this search mechanic tells > me that either there is lack of or little documentation, and lack of or > little understanding of the codebase in which the code resides thereby > making this argument flawed based solely on the assumption that the > majority of code is (or should be) poorly maintained/documented. > > Below is simply bad programming practice in many ways. No validation of > type (neither through type-hinting nor an instanceof check) is done, which > is why the code is so difficult to trace back. Presumably, you'd also have > some form of documentation (PHPDoc, anyone?) that would facilitate the > search for the declaration of that function. Again, that assumes a better > programming practice than is being provided as the example below. One > would hope that someone excluding their function keyword would also be "up > to date" enough to be validating objects. > > > function baz( $param ) { > > > > $param->morlocks(); > > > > } I would like to know how to get to the fantasy world you describe in which all developers are doing careful type checking and proper DocBlocks on everything. It sounds like it would be a glorious place to live, if only it could exist. (I routinely beat people over the head about that in a project with very good documentation standards, and we still have extremely good developers writing code that fails both of the above.) --Larry Garfield

« previous php.internals (#50673) next »