[PHP-DEV] 回复: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

2013-03-06 Thread Reeze Xia
Hi Nikita,
I got some test failure with the patch, one test failure and some memory 
leaks.
see: https://gist.github.com/reeze/5101596


--  
reeze | reeze.cn

已使用 Sparrow (http://www.sparrowmailapp.com/?sig)  

在 2013年3月7日星期四,上午1:28,Dmitry Stogov 写道:

 On Wed, Mar 6, 2013 at 9:16 PM, Nikita Popov nikita@gmail.com 
 (mailto:nikita@gmail.com) wrote:
  
  On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov dmi...@zend.com 
  (mailto:dmi...@zend.com) wrote:
   
   Hi Nikita,

   few notes about the patch...

   - you may avoid estrndup() in zend_hash_current_key_zval_ex() for
   interned strings.

   
   
  Good idea, I'll do that.
   

   - I didn't completely get why did you change the key operand type from
   IS_TMP_VAR to IS_VAR and how it affects performance
   As I understood now you need to allocate new zval on each loop iteration
   even for foreach over plain arrays. :(

   
   
  Good point, I didn't consider the performance implication the type change
  would have. The intent behind that was to avoid copying the get_current_key
  zval into the temporary (and destroying it then), but I didn't consider how
  it affects normal arrays. This should be changed back to TMP_VAR.
   
  
  
 It would be great. I can agree that new features may work slower, but
 really don't like when they slowdown existing and mach more usual cases.
  
  
   
  I wonder what would be a good way to avoid allocating a temporary zval for
  the key and freeing it again. Do you think it would be okay to pass
  EX_T((opline+1)-result.var).tmp_var into -get_current_key() so the value
  can be written directly into it without doing extra allocs/frees?
   
  
 I'm not sure it'll work. TMP_VARs don't initialize refcount, they can't be
 referenced or marked as a possible root of garbage.
 I took only a very quick look over the patch and didn't understand all the
 details, but probably it must be possible to copy iterator key into TMP_VAR
 and call copy_ctor().
  
 Please, let me review the patch when it's ready (I won't be available on
 March 8 and weekend).
  
 Thanks. Dmitry.  



[PHP-DEV] 回复: [PHP-DEV] Current Status of O+ on Windows

2013-03-02 Thread Reeze Xia
+1 s, Switch to a new opcode cacher is much easier than update PHP,  
and ZO+ is already compatible with 5.5. we could use ZO+ as soon as possible.
--  
reeze | reeze.cn

已使用 Sparrow (http://www.sparrowmailapp.com/?sig)  

在 2013年3月2日星期六,下午4:43,Ferenc Kovacs 写道:

 On Sat, Mar 2, 2013 at 9:39 AM, Zeev Suraski z...@zend.com 
 (mailto:z...@zend.com) wrote:
  
   -Original Message-
   From: Ferenc Kovacs [mailto:tyr...@gmail.com]
   Sent: Saturday, March 02, 2013 10:15 AM
   To: Pierre Joye; Dmitry Stogov
   Cc: Christopher Jones; Matt Ficken; internals@lists.php.net 
   (mailto:internals@lists.php.net)
   Subject: Re: [PHP-DEV] Current Status of O+ on Windows

 Did you experiment with any options?
 Putting the date of your O+ snapshot would also be handy.
  
 
 
Latest from here are used:
http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/
 
Dates are included. It would be nice to have it in the report as well,
but we always use latest revision. It would however be much easier if
there were PECL releases.
 

   +1
   Dmitry, is there any objection against creating a pecl release?
   Could you tag the first version?

   
   
  The current vote that's going on right now deals with putting the extension
  into PHP itself. If that happens (which seems awfully likely at this
  point), why do we need it in PECL? We'd very much rather invest our very
  limited cycles into the code itself. We're probably roughly a week away
  from having builds as a part of the PHP 5.5 snaps.
   
  Zeev
  
 I see.
 so no O+ for 5.5?
 having a pecl release would be a small amount of work, which I would glad
 to help with.
  
 --  
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu
  
  




[PHP-DEV] 回复: [PHP-DEV] [RFC] Remove calls with incompatible Context

2012-08-03 Thread Reeze Xia


在 2012年8月4日星期六,上午6:40,Andrew Faulds 写道:

 On 03/08/12 23:36, Etienne Kneuss wrote:
  On Mon, Jul 30, 2012 at 7:31 PM, Gustavo Lopes glo...@nebm.ist.utl.pt 
  (mailto:glo...@nebm.ist.utl.pt) wrote:
   https://wiki.php.net/rfc/incompat_ctx

   An RFC for deprecating and removing $this from incompatible context.

   Comments are welcome.
  4+ years ago Marcus already wanted to clean that up in PHP6.
   
  Definitely +1.
   
  Best,
   --
   Gustavo Lopes

   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php

   
   
  
 While we're at it,
  
 $a = 'this';
 $$a = new StdClass();
  
 should be an error.
 Also $GLOBALS['this'] = new StdClass();
  
 https://bugs.php.net/bug.php?id=52428
then so does: extract(array('this' = 'scalar')); and the similar situation 
that may import variables.

  
 --  
 Andrew Faulds
 http://ajf.me/
  
  




[PHP-DEV] 回复: [PHP-DEV] Re: 回复: [PHP-DEV] [RFC] Proposal namespace importing with from syntax

2012-07-25 Thread Reeze Xia
Hi,  

在 2012年7月25日星期三,下午1:27,Laruence 写道:

 Hi:
  
 is there any really usage? I didn't see before. I don't think every
Yes, eg: 
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityRepository.php#L24

it could be:
from Doctrine\Common\Collections use ExpressionBuilder, Criteria, 
ArrayCollection, ExpressionBuilder;

The Motivation is that I found many projects that use namespace have the 
problem of repeat type
the same namespace again and again.  
 python feature is proper for PHP. PHP is not python.
  
  

I think it could be useful to reduce duplication, but not copy everything from 
Python.
like many useful features we borrowed from other languages ;-)
  
 -1 on this RFC
  
 +1 for Stas
  
 and one more thing, BC break.
Yes, introduce new features may break things, eg the new trait,insteadof in 
5.4, and maybe  
the comming finally, yield etc. but if it is desired, I think it may worth it.  

Thanks for your feedback!
  
 there are many ORM or DB warpper libraries defines `from` method, like:
  
 $db-select()-from();
  
 thanks
  
 On Wed, Jul 25, 2012 at 1:22 PM, Stas Malyshev smalys...@sugarcrm.com 
 (mailto:smalys...@sugarcrm.com) wrote:
  Hi!
   
   No, we can not import namespace directly for now :
   
  Of course you can. You just missing on what namespace import means in
  PHP, it's not like Java (though a bit like Python).
   
   ?php
   namespace A {
   class B {}
   }

   namespace {
   use A;

   var_dump(new B());
   }

   
   
  use A is a no-op, just as the warnings tell you. You can just write A\B.
  It's only 2 characters more. If your A is longer, then you can alias it
  to something shorter.
   
   and if we need alias we could:
   ?php
   // reduce
   use GlobalNamespace\SubSpace\ThirdSpace\Class1;
   use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
   use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;

   
   
  You could just do
  use GlobalNamespace\SubSpace\ThirdSpace as Spc;
  $a = new Spc\Class1();
   
  
  
  

Hi Stas,  
That is what I am trying to propose, maybe it could be more DRY?

thanks :)
   
   
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227
   
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
   
  
  
  
  
 --  
 Laruence Xinchen Hui
 http://www.laruence.com/
  
  




[PHP-DEV] 回复: [PHP-DEV] [RFC] Proposal namespace importing with from syntax

2012-07-24 Thread Reeze Xia
Hi Stas,  

在 2012年7月25日星期三,上午2:33,Stas Malyshev 写道:

 Hi!
  
  from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, 
  ForthSpace\Class3 as Alias3;
  
 I'm not sure it's necessary. If you import a real lot of the classes
 from the same namespace, just import the parent namespace. And this
  
  

No, we can not import namespace directly for now :
?php
namespace A {
class B {}
}

namespace {
use A;

var_dump(new B());
}

Warning: The use statement with non-compound name 'A' has no effect in 
/Users/reeze/Opensource/php-test/php-src-master/a.php on line 7

if we wan to archive the goal of import anything. the only way is to declare 
the current namespace  
as  the parent namespace we want to import from, eg:

?php
namespace Zend {
class B {}
}

namespace *Zend* {

var_dump(new B());
}

but this is not preferred for use code declared as the library we used.
 syntax makes less clear what is the true name of Class2 and also by
 similarity to python syntax would lead people to think it does the same
 thing python one does - which it is not.
  
  

Sorry, I didn't make myself clear. the example I posted is not correct. It 
didn't have to alias the imported classes.
'use' statement can alias the imported class too, the proposed 'from xx use yy' 
is almost  
the same as 'use'

The correct example should be:

?php
// if we don't want to duplicated then the follow could be
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2;
use GlobalNamespace\SubSpace\ThirdSpace\Class3;
// reduced to
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2, Class3 ;
?


and if we need alias we could:
?php
// reduce  
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;
// to
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, 
ForthSpace\Class3 as Alias3;
?


Thanks stas.
  
  
 --  
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227