On 17 Jan 2012, at 06:42, Stas Malyshev wrote:
> Hi!
>
>> Now especially for traits it delays resolution of special constant
>> __CONST__ til run-time.
>
> Looks good, I don't see any problems with it so far. If nobody else does,
> let's commit it,
I only had a chance to have a very brief loo
Hi!
Now especially for traits it delays resolution of special constant
__CONST__ til run-time.
Looks good, I don't see any problems with it so far. If nobody else
does, let's commit it,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PH
On 01/16/2012 11:25 AM, Stefan Marr wrote:
> I would argue that __FILE__ and __LINE__ are not referring to conceptual
> entities, but the literal code. And, I guess, they are mostly used for
> debugging purposes to identify the relevant code. Thus, I would not change
> them, but keep them as com
Hi,
The updated patch is attached.
Now especially for traits it delays resolution of special constant
__CONST__ til run-time.
Thanks. Dmitry.
On 01/15/2012 06:56 AM, Stas Malyshev wrote:
Hi!
What would be the best approach to handle the case of property
definitions?
I don't think this o
Hi:
On 16 Jan 2012, at 11:15, yoram bar haim wrote:
> 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 c
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, J
Hi Stefan,
It couldn't be done using early binding.
It should be done delaying __CLASS__ constant resolution till run-time.
Doing this we can even substitute he proposed ZEND_CLASS_NAME with
ZEND_FETCH_CONSTANT(__CLASS__). For default values we'll have just store
the corresponding constant.
I
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 an
Stas,
Thank you for looking into it and finding out a new problem :)
I'll take a look into it and will try to fix.
Dmitry.
On 01/13/2012 10:53 PM, Stas Malyshev wrote:
Hi!
As I understood the copying was done only for proper handling of
__CLASS__ constant in trait methods. I think it's too r
Hi Dmitry:
After Stas nice and encouraging words, I had another look.
But to me it seems that I am not able to get to any of the relevant bits via
the scoping infos in the globals. And I do not see how we could encode
something into ZEND_CLASS_NAME.
But I don't have a good overview of the engin
Hi!
What would be the best approach to handle the case of property
definitions?
I don't think this opcode should be there in this case. Maybe we should
use IS_CONSTANT in this case and handle it when constants are updated as
a special case?
Alternatively, if we find no solution for it we may
Hi Dmitry:
On 14 Jan 2012, at 01:24, Stefan Marr wrote:
> On 13 Jan 2012, at 19:53, Stas Malyshev wrote:
>
>> trait foo {
>> public $bar = __CLASS__;
>> }
>
> Breakpoint 3, zend_do_early_binding () at zend_compile.c:4602
> 4602 zend_error(E_COMPILE_ERROR, "Invalid bind
Hi Stas:
On 13 Jan 2012, at 19:53, Stas Malyshev wrote:
> I've done some checks and discovered __CLASS__ behaves somewhat strangely
> with traits. COnsider this code:
>
> trait foo {
> public $bar = __CLASS__;
> function bar() { var_dump($this->bar); }
> }
>
> class foofoo {
>use foo;
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 opcod
Hi!
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
adding david too to the loop.
On Fri, Jan 13, 2012 at 10:36 AM, Dmitry Stogov wrote:
> Hi,
>
> Recently we've found a huge problem in PHP traits implementation.
>
> It performs copying of each op_array (with all opcodes!) for each method
> used from trait. This not only makes traits extremely slo
Hi Lester:
On 13 Jan 2012, at 11:51, Lester Caine wrote:
> If developments like this slow down the general performance of PHP
There shouldn't be any significant performance impact of the traits addition to
the engine.
Traits only cost you if you use them, and their cost is restricted to
compi
On 01/13/2012 11:51 AM, Lester Caine wrote:
why would I not put this code into a base class and simply extend
from that.
Could you please refrain from asking questions such as this BEFORE you
even bothered to research the topic? Thank you very much.
--
Sebastian BergmannC
On 01/13/2012 11:51 AM, Lester Caine wrote:
If developments like this slow down the general performance of PHP,
then they need to be able to be disabled as well
While we're at it we can also add configuration directives to disable
namespaces, classes, functions, and every syntax features that
On Fri, Jan 13, 2012 at 11:51 AM, Lester Caine wrote:
> (Several cc's removed)
>
>
> Stefan Marr wrote:
>
>> Sorry, but I am a bit annoyed that 'the community' does not care enough
>> about reviewing such engine changes.
>>
> I feel that it is worth pointing out that there still needs to be a cas
(Several cc's removed)
Stefan Marr wrote:
Sorry, but I am a bit annoyed that 'the community' does not care enough about
reviewing such engine changes.
I feel that it is worth pointing out that there still needs to be a case made
for the general use of traits. Currently I see no advantage to us
Hi Stefan,
On 01/13/2012 02:13 PM, Stefan Marr wrote:
Hi Dmitry:
On 13 Jan 2012, at 10:36, Dmitry Stogov wrote:
Recently we've found a huge problem in PHP traits implementation.
Thanks for taking care of it, but just to be explicit here: I pointed out the
implementation details in the vari
Hi:
On 13 Jan 2012, at 11:13, Stefan Marr wrote:
> From the top of my head, it is the handling of __CLASS__ and the handling of
> static variables in methods. You did not mention that, is it taken care of
> explicitly, or do traits now share static state? The later would not be
> intended. Wil
Hi Dmitry:
On 13 Jan 2012, at 10:36, Dmitry Stogov wrote:
> Recently we've found a huge problem in PHP traits implementation.
Thanks for taking care of it, but just to be explicit here: I pointed out the
implementation details in the various discussions. I never made it 'a secret'
that there i
On 01/13/2012 10:36 AM, Dmitry Stogov wrote:
It performs copying of each op_array (with all opcodes!) for each method
used from trait.
That is bad, indeed.
As result some extensions (e.g. xdebug and some Zend extensions) will
just crash on traits usage.
I have used PHP 5.4-dev, Xdebug 2.2
25 matches
Mail list logo
