2010/11/28 Ángel González <keis...@gmail.com>
> Dallas Gutauckis wrote:
> > Just to be clear, this works on the assumption that we don't know the
> class
> > name that the function resides in?
> >
> > I understand the search argument, but to me it only applies to functions,
> > not methods. Is anyone arguing for removing the T_FUNCTION requirement on
> > functions?
>
> Even knowing the class you are calling, and assuming the common
> convention of
> one file per class, you may not know in which file is it implemented.
> It's annoying
> to go into the class, find out it's not there, grep the parent class,
> and having to
> repeat the process three or four levels up.
> Whereas with a unique enough name, grepping the functions get all the
> possible
> implementations.
>
> Plus, it's not always easy to know in which class to look something :-)
>
>
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();
> }
>
>
