If we want __CLASS__ to be resolved at runtime (at list in case of trait), then what about __FILE__ and __LINE__ ? should they be resolved at compile time and reflect the original code in the trait or should they reffer to the using class (which is a problem for the __LINE__ ...) ?
On Monday, January 16, 2012 08:33:04 AM Dmitry Stogov wrote: > On 01/14/2012 03:34 AM, Stefan Marr wrote: > > Hi Dmitry: > > > > On 13 Jan 2012, at 10:36, Dmitry Stogov wrote: > >> As I understood the copying was done only for proper handling of > >> __CLASS__ constant in trait methods. I think it's too radical > >> solution. I've introduced ZEND_CLASS_NAME instruction instead and made > >> op_arrays to share their opcodes (in the same way as inherited > >> methods). The only difference that methods from traits may be renamed. > >> > >> The patch is attached (it requires executor/scanner/parser regeneration) > >> I would like to commit it into 5.4 and trunk. Note that the patch makes > >> binary compatibility break and can't be applied to 5.4.* after 5.4.0 > >> release. > > > > I looked at the patch, looks good as far as I can see. > > > > The comment in zend_traits_copy_function (has a typo 'destroied') makes > > me wonder what it means exactly. Does it mean we got a memory leak with > > regard to trait aliases? > > No. We might get a memory leak or double free in case trait is destroyed > before the class that used it and renames some of its methods. > > > And, I would have one stylistical request: could you separate out the > > optimizations you do in zend_language_scanner.l? I think it would be > > better to have the proper use of interned strings committed on their > > own. Especially, since they regard not only trait-related functionality. > > OK. > > Thanks. Dmitry. > > > Thanks > > Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
