Results for project PHP master, build date 2017-02-06 20:29:14-08:00
commit: 31332d0
previous commit:795a4c1
revision date: 2017-02-06 01:47:09+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 2/7/17 3:22 PM, Scott Arciszewski wrote:
One such real-world use case: Defuse v1 used HKDF without a salt.
https://github.com/defuse/php-encryption/blob/b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L157-L170
https://github.com/defuse/php-encryption/blob/b87737b2eec06b13f025cabea847338f
On 7 February 2017 at 17:56, Scott Arciszewski wrote:
> I'm taking all the No votes spawned by this thread to mean "we
> don't want namespaced functions ever".
That would be a bad assumption.
Peter Cowburn wrote:
> Slinking in a vote which essentially is about adopting
> namespaces in core, via
On Tue, Feb 7, 2017 at 2:35 PM, Yasuo Ohgaki wrote:
> Hi Nikita, Andrey and all,
>
Regards,
>
> P.S. I'll be more careful, but I become very sloppy mail reader sometimes.
> I appreciate if you could let know via private email. Thank you!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
Hi,
Hi Ilija,
On 7 February 2017 18:58:15 GMT+00:00, ilija.tov...@me.com wrote:
>And also, have you considered letting people vote for their preferred
>arrow function syntax?
>I kinda don’t think we’re gonna find an agreement as there are so many
>different opinions.
The problem with voting on altern
Hi Nikita, Andrey and all,
My apologies, I misread mails by super sloppy reading.
I'll explain basis by my idea clearly and properly this time.
This mail is long.
Basis of my idea is
- Salt is made to optional only for applications that such value is not
available. (From RFC 5869)
- Omitting sa
Hey everyone
I’m on team C as well.
One complaint about the RFC is that it doesn’t support multi-statement bodies.
Arrow functions are especially useful for functional programming where it’s
common to return a value in a single expression. Using multiple statements
(partly) destroys the useful
On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder wrote:
> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about thi
On 2/7/2017 11:39 AM, Niklas Keller wrote:
> I don't see this as a potential problem. Autoloadeds are (1) not triggered
> for already loaded symbols and (2) and more importantly, autoloaders
> usually use a list of prefixes to load, so a whitelist, not a blacklist.
>
> Regards, Niklas
>
This is
There will be breaking changes for the sodium users anyways since some
functions will not be included and the complete error handling needs to
be changed from errors to exceptions.
--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
On Tue, Feb 7, 2017 at 12:00 PM, Derick Rethans wrote:
> On Mon, 6 Feb 2017, Nikita Popov wrote:
>
> > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder
> wrote:
> >
> > > First: I like namespaces in Core but here me out!
>
>
>
> > I'm strongly against use of the PHP namespace as a blanket namespace
On Tue, 7 Feb 2017, Rowan Collins wrote:
> On 7 February 2017 11:25:53 GMT+00:00, Wes wrote:
>
> >But even better, it would be nice if debug_zval_dump() always
> >returned the debug information unaffected by custom user-defined
> >__debugInfo. This is by the way what HHVM does:
> >https://3v4l
On 7 February 2017 11:25:53 GMT+00:00, Wes wrote:
>But even better, it would be nice if debug_zval_dump() always returned
>the
>debug information unaffected by custom user-defined __debugInfo. This
>is by
>the way what HHVM does: https://3v4l.org/OoJkC
While it might be a good idea to have a way
Hello Internals.
Today I'm fighting with some code that I think uses var_dump() and output
buffering to create the output for __debugInfo... or something like that -
I'm not really interested into finding the cause :P
Anyway, It's not the first time I find myself paralyzed by a slightly
broken __d
On Mon, 6 Feb 2017, Stanislav Malyshev wrote:
> > I'm strongly against use of the PHP namespace as a blanket namespace
> > for bundled PHP extensions. The PHP namespace should be used only
> > for functionality that is actually in some way related to PHP. For
> > example, the php-ast extension
On Mon, 6 Feb 2017, Sara Golemon wrote:
> On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov wrote:
>
> > I'm strongly against use of the PHP namespace as a blanket namespace
> > for bundled PHP extensions. The PHP namespace should be used only
> > for functionality that is actually in some way relat
On Mon, 6 Feb 2017, Nikita Popov wrote:
> On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder wrote:
>
> > First: I like namespaces in Core but here me out!
> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
>
> I thought about this too. I hope you understood that the main reasoning
> for me to choose a well known namespace prefix is related to
> auto-loading and when to trigger it. The lack of function and constant
> auto-loading is a pain and having well known prefixes could solve the
> issue since w
"Stanislav Malyshev" wrote in message
news:a8d24d41-bd3a-0881-3fcb-9366fe974...@gmail.com...
Hi!
New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)
Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \ph
"Fleshgrinder" wrote in message
news:04295b76-3e0d-5ea3-7b4e-d07a15db4...@fleshgrinder.com...
On 2/6/2017 9:47 PM, Nikita Popov wrote:
I'm strongly against use of the PHP namespace as a blanket namespace
for bundled PHP extensions. The PHP namespace should be used only
for functionality that
Hi Dave,
I don't see a big value in this new addition, however, I also don't see any
harm.
I added few minor comments about implementation at
https://github.com/php/php-src/pull/2371
Please, review and update implementation accordingly.
Thanks. Dmitry.
From
On 07/02/17 08:53, Rowan Collins wrote:
>> I think the Sodium RFC vote is not about namespace but rather about
>> breaking everything which already use the pecl extension.
> Well, it's about both, that's why it's a hard question: in order not to break
> existing use of the extension, we need to br
Just my two cents, but moving and aliasing core PHP
classes/interfaces/functions sounds like an absolutely horrible idea.
My biggest question is WHY would you do that?
Writing user-space code today that uses the global namespace would be
considered extremely bad practice - no one should do that.
On 7 February 2017 06:52:32 GMT+00:00, Remi Collet
wrote:
>> https://wiki.php.net/rfc/libsodium
>
>I think the Sodium RFC vote is not about namespace but rather about
>breaking everything which already use the pecl extension.
Well, it's about both, that's why it's a hard question: in order not t
24 matches
Mail list logo
