On 4/12/12 10:09, "Anthony Ferrara" <ircmax...@gmail.com> wrote:
>I'm not against the idea, I just don't see a strong use-case for it. >It's not like your injecting the scoped vars into an existing >function, you're writing the function fresh. So why not just use the >existing var names? I can see this being occasionally useful. For example, consider a closure that has many references to the used variables. Such a function might want to use very short variables names for clarity and brevity (think something like a complex comparison function). If the parent scope uses longish names (which may be great in the parent scope), the closure is either stuck with them or forced to assign new variables. Also, remember that the closure is in fact another function, a function that performs its own actions independent of the parent. Just as other functions can pick whatever parameter names make the most sense to them internally, I think it makes sense to allow closures to pick whatever used-variables names make the most sense to them internally. It's certainly not a requirement, but used judiciously, I think it can definitely lead to easier-to-read (i.e., easier-to-maintain) code since it means variables can be named to best reflect their usage in both parents and closures. -Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
