Re: Urgent patch for traits in PHP 5.4
| From: | yoram bar haim | Date: | Mon, 16 Jan 2012 10:15:42 +0000 |
| Subject: | Re: Urgent patch for traits in PHP 5.4 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-57373@lists.php.net to get a copy of this message | ||
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