Re: RFC: Making T_FUNCTION optional in method declarations
| From: | David Otton | Date: | Sun, 28 Nov 2010 22:51:47 +0000 |
| Subject: | Re: RFC: Making T_FUNCTION optional in method declarations | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-50674@lists.php.net to get a copy of this message | ||
2010/11/28 Dallas Gutauckis <dallas@gutauckis.com>:
> 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.
Yes. Absolutely. The majority of code /is/ poorly maintained and
documented. I work with scrappy codebases that have seen dozens of
devs over their lifetimes, and this patch removes one of the few
certainties - that 'grep "function X"' is absolutely the fastest way
to find the place where X is declared. I'm not an internals guy, so I
can't vote, but I will ask you to reconsider this one.
2010/11/28 Ross Masters <ross@php.net>:
> From what I understand T_FUNCTION would be optional, rather than removed
> altogether, is this the case? This would allow those who want to use it the
> option of using it and would not break existing code.
My worry is that the last-guy-but-five used the new syntax and now I
have to apply a fix to his code. Yeah, I'll find the function on my
second/third attempt, but it is an impediment.