Re: [PHP-DEV] RFC - Immutable classes

On 09/13/2016 02:07 AM, Larry Garfield wrote: > On 09/12/2016 06:47 PM, Stephen Reay wrote: >>> Ah, I did see that one, but there was a lot of discussion after it >>> so I thought the idea evolved. Response below based on skimming the >>> responses after that as well... >>> >>> It sounds like

Re: [PHP-DEV] Directly embed small strings in zvals

Hi, I was skeptical about this idea, but the PoC looks interesting and quite simple. This might be too big change for 7.*, if we won't completely hide implementation details for extensions using existing macros... I'm not sure if this will lead to performance improvement. On one hand, we

Re: [PHP-DEV] Directly embed small strings in zvals

Hi Ben! Benjamin Coutu wrote: I was wondering if it would make sense to store small strings (length <= 7) directly inside the zval struct, thereby avoiding the need to extra allocate a zend_string, which would also not entail any costly indirection and refcounting for such strings. The idea

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-09-13

Results for project PHP master, build date 2016-09-13 06:24:51+03:00 commit: 409ff32 previous commit:ca5cfac revision date: 2016-09-12 17:36:33-04:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Directly embed small strings in zvals

Hello everyone, I was wondering if it would make sense to store small strings (length <= 7) directly inside the zval struct, thereby avoiding the need to extra allocate a zend_string, which would also not entail any costly indirection and refcounting for such strings. The idea would be to add

[PHP-DEV] Re: pdo_dblib on pecl

> > > I noticed that there's a stale version of a supported package on pecl: > > https://pecl.php.net/package/pdo_dblib > > > > Should this be removed to avoid confusion? > > Alternatively a note might be added, as it has been done for > PECL/domxml, for instance. > > Either way, that should also

Re: [PHP-DEV] Re: pdo_dblib on pecl

On 13/09/2016 14:07, Christoph M. Becker wrote: On 13.09.2016 at 14:53, Adam Baratz wrote: I noticed that there's a stale version of a supported package on pecl: https://pecl.php.net/package/pdo_dblib Should this be removed to avoid confusion? Alternatively a note might be added, as it has

[PHP-DEV] Re: pdo_dblib on pecl

On 13.09.2016 at 14:53, Adam Baratz wrote: > I noticed that there's a stale version of a supported package on pecl: > https://pecl.php.net/package/pdo_dblib > > Should this be removed to avoid confusion? Alternatively a note might be added, as it has been done for PECL/domxml, for instance.

[PHP-DEV] pdo_dblib on pecl

Hi, I noticed that there's a stale version of a supported package on pecl: https://pecl.php.net/package/pdo_dblib Should this be removed to avoid confusion? Thanks, Adam

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

I don't think anyone is arguing that literally no one is using PEAR packages, but looking at the ~6 months old archive.org mirror of http://pear.php.net/package-stats.php (available at https://web.archive.org/web/20160315083551/http://pear.php.net/package-stats.php), the largest package, PEAR

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Rowan, On Tue, Sep 13, 2016 at 6:47 PM, Rowan Collins wrote: > To me, uniqid() is useful because it is a quick way of getting a short > string that's likely to be fairly unique. If that is its purpose, then > making it slower, and its output longer, are not helping

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, 12 Sep 2016, Niklas Keller wrote: > 2016-09-12 10:21 GMT+02:00 Derick Rethans : > > > On Mon, 12 Sep 2016, Pierre Joye wrote: > > > > > This RFC is about stop bundling it with the php releases and propose > > > composer/pickle instead. Everything else has nothing to do

Re: [PHP-DEV] RFC - Immutable classes

On 13/09/16 00:47, Stephen Reay wrote: > Regarding identity, I’m going to refer back to the DateTimeImmutable class. I > know its not the same implementation, but honestly I don’t think that > matters. Developers use PHP because they generally *don’t* have to worry > about the internal details

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

On 13/09/2016 02:07, Yasuo Ohgaki wrote: I pasted simple benchmark to the PR. New code uses about 2x cpu time on my Fedora 24. CSPRNG uses more complex code than php_combined_lcg(), so this is expected. To me, this is at least as important as changing the length and character range of the

Re: [PHP-DEV] Modern practices ...

On 13/09/16 01:44, Pierre Joye wrote: > On Tue, Sep 13, 2016 at 3:06 AM, Lester Caine wrote: >> On 12/09/16 20:31, Christoph M. Becker wrote: >>> On 11.09.2016 at 12:35, Lester Caine wrote: >>> On 11/09/16 11:05, Christoph M. Becker wrote: >>> I have already debugged

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Sent: Monday, September 12, 2016 12:34 PM >To: Tony Marston >Cc: Sherif Ramadan ; Stanislav Malyshev ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > >On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston wrote: > >Sent:

Re: [PHP-DEV] RFC - Immutable classes

Proposed operator overloading and magic methods to compare with other objects is very good idea, I like it a lot, there even may be additional restriction provided with my other RFC https://wiki.php.net/rfc/object-typehint But I think this goal should be provided in separate RFC as it is very

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kauzo, On Tue, Sep 13, 2016 at 3:23 PM, Kazuo Oishi wrote: >> Current implementation is good enough for most cases, but it can be better. > > I agree this legacy design API works good enough for most cases. > > So, I think it should not be changed in BC break way. I updated

Re: [PHP-DEV] RFC - Immutable classes

Thanks a lot for your feedback. I like the clone idea too and I also see no harm in allowing them in any context rather than only in immutable classes. I am really against the transformer keyword, don't ask me why, I just don't like it at all. :P I mentioned before that PHP should allow for

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi, >> The uniqid() manual explicitly say, >> >> - default value of more_entropy is false >> >> - the returned string will be 13 characters long. If more_entropy is >>TRUE, it will be 23 characters. >> >> - if more_entropy is set to TRUE, uniqid() will add additional entropy >>(using