[PHP-DEV] BAD Benchmark Results for PHP Master 2017-02-06

[lp_benchmark_robot]

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
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.24% -0.47% -0.26%  
  7.58%
:-|   Drupal 7.36 cgi -T1  0.23% -0.41%  0.01%  
  4.91%
:-|   MediaWiki 1.23.9 cgi -T5000  0.16%  0.00%  1.16%  
  3.30%
:-|   bench.php cgi -T100  0.01% -0.01% 38.03%  
 -7.09%
:-|  micro_bench.php cgi -T10  0.00%  0.15% 14.62%  
  1.97%
:-(  mandelbrot.php cgi -T100  1.57% -2.68% 28.91%  
 -7.68%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-02-06/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] hash_hkdf() signature

[Tom Worster]

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/b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L358

In version 2, we included a 32-byte random salt for each encryption, 
which
was stored next to the AES-256-CTR nonce in the ciphertext. (Both the 
nonce
and HKDF-salt, as well as the version information header, are covered 
by

the HMAC of the ciphertext.)

The end result: Instead of having to worry about birthday collisions 
after
you've seen 2^64 AES outputs (because 128-bit randomly generated 
nonce),

now you need 2^192 before you have a useful collision.


In this situation shouldn't you either use a longer random IKM or not 
use HKDF at all?


If your IKM is so weak that it needs a salt then shouldn't you use an 
iterated hash instead of HKDF?


Tom

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

Re: [PHP-DEV] Namespaces in Core

[Dan Ackroyd]

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 new library RFC, is not the way to go about
> changing our coding standards.  In short, I don't want to the see the
> situation where this extension gets merged in to 7.2 (which it should be
> :)) only to have someone ask, "what about the 'php' top-level namespace?"
> and we all shrug and mutter, "too late" under our breaths.

aka it should be a separate discussion to whether libsodium should be
included in PHP7.2.

cheers
Dan

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

Re: [PHP-DEV] hash_hkdf() signature

[Scott Arciszewski]

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,​

Although there are HKDF usage without salt, many HKDF applications with PHP
> require or are better with salt. e.g. Previous per-session encryption.
> Developers
> will develop better application if they consider how salt could be used.
> Therefore,
> salt is better to be required parameter and omit it only when salt cannot

be used.​
>
>
​---​

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/b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L358

In version 2, we included a 32-byte random salt for each encryption, which
was stored next to the AES-256-CTR nonce in the ciphertext. (Both the nonce
and HKDF-salt, as well as the version information header, are covered by
the HMAC of the ciphertext.)

The end result: Instead of having to worry about birthday collisions after
you've seen 2^64 AES outputs (because 128-bit randomly generated nonce),
now you need 2^192 before you have a useful collision.

Although the RFC itself says that salts are optional, the argument to make
them required in PHP's implementation has merit. The only downside is: If
you're integrating with an implementation that doesn't require salts, and
the application doesn't use salts, you're out of luck. Is that enough of a
downside to dismiss an argument for better security? Maybe.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises ​

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

[Rowan Collins]

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 alternative syntaxes is precisely that there *are* 
so many different options. Designing a vote with multiple options that gives an 
answer people are happy with is a whole science in itself.

I think the best we can do is have a "without prejudice" vote on a single 
proposal - if it is declined, a new proposal can be made after a suitable 
period of reflection. This has already happened once with this very topic, this 
RFC having emerged from a previous one being rejected.

That doesn't mean we can't discuss other syntaxes, but just opening up all 
possible options to a vote doesn't really help IMHO.

Regards,

-- 
Rowan Collins
[IMSoP]

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

[PHP-DEV] hash_hkdf() signature

[Yasuo Ohgaki]

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 salt could lead to security disaster. i.e. password leak.
 - Combined key, output key and salt, as final key(combined key) is common
in many use cases.
 - Many HKDF applications with PHP must/should have salt for better
implementation.
 - API should encourage "salt" use by its signature. (From RFC 5869)

Ref: https://tools.ietf.org/html/rfc5869

Before restart discussion, there should be rationale for others.

In theory, cryptographic hashes are cryptographically secure. Therefore,
following operations should be considered as secure by definition.

$new_key = sha1('some original key' . 'strong salt' . 'some info');
$signature = sha1('some data' . 'strong key');

However, in real world, people come up with better idea for cryptographic
hashes. Sometimes people invent efficient way to attack cryptographic
hashes.

HMAC is known and proven method to generate more secure signature.
Therefore,
$signature = hash_hmac('sha1', 'some data', 'some key');
is secure even when cryptographic hash had minor defect(s).

HKDF is made to generate secure new keys from existing key suitable
for required operations by using HMAC.
HKDF inputs
 - IKM, input key which may be weak or strong
 - salt, some entropy which makes HKDF stronger overall, may be secret or
non secret/weak or strong.
 - info, which specifies HKDF contexts that are non secret usually. e.g. a
protocol number, algorithm identifiers, user identities, etc.
 - length(L), output key length

HKDF calculates output key(OKM) as follows

Extract step
   PRK = HMAC-Hash(salt, IKM)

This step is designed to make strong output key(OKM) and PRK always.
OKM to be secure, either IKM or salt must be strong.

Expand step
   N = ceil(L/HashLen)
   T = T(1) | T(2) | T(3) | ... | T(N)
   OKM = first L octets of T

   where:
   T(0) = empty string (zero length)
   T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
   T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
   T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)

Note: OKM is output key material that is return value from HKDF.

This step is designed to make derived key have the length(L) from
strong key(PRK) generated by Extract step. Key context(info) is
distinguished by this step also.


Both salt and info is optional, but RFC 5869 states differently.

  "HKDF is defined to operate with and without random salt.  This is
   done to accommodate applications where a salt value is not available.
   We stress, however, that the use of salt adds significantly to the
   strength of HKDF, ensuring independence between different uses of the
   hash function, supporting "source-independent" extraction, and
   strengthening the analytical results that back the HKDF design."

This statement implies salt is almost mandatory parameter for HKDF
when salt can be used. In contrast, info is described as pure optional
parameter for key context.

  "While the 'info' value is optional in the definition of HKDF, it is
   often of great importance in applications.  Its main objective is to
   bind the derived key material to application- and context-specific
   information.  For example, 'info' may contain a protocol number,
   algorithm identifiers, user identities, etc."

With regard to mandatoriness parameters, strong salt is mandatory to derive
cryptographically strong key when input key is weak, while info/length is
optional always.

In addition, it is common that salt being used as a part of combined keys.
Salt is mandatory for such applications. There are many authentication
implementations that use
 - key which does not disclose original key by hashing
 - nonce(salt)

Access permission with timeout is another typical usage that requires
timestamp as salt and combined key.

HKDF can produce secure key, which protects input key(IKM) and
generates strong output key (OKM), but this is true only when
IKM or salt is strong. Use of weak IKM and salt could lead password leak.


For above reasons, I'm proposing change
   string hash_hkdf(string $hash, string $ikm [, int $length=0 [, string
$info='' [, string $salt='']]])
to
   string hash_hkdf(string $hash, string $ikm, string $salt [, string
$info='' [, int $length=0 ]])
 - To omit salt, $salt=NULL. $salt='' raise exception.


On Mon, Jan 16, 2017 at 8:08 PM, Nikita Popov  wrote:

> Making the salt required makes no sense to me.
>
> HKDF has a number of different applications:
> a) Derive multiple strong keys from strong keying material. Typical case
> for this is deriving independent encryption and authentication keys from a
> master key. This requires only specification of $length. A salt is neither
> necessary nor useful in this case, because you start with strong
> cryptographic keying material.
>

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

[ilija . tovilo]

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 usefulness of the arrow function as that would require a 
`return` keyword, braces and semicolons.

Additionally, long closures with multiple statements may actually benefit from 
not implicitly capturing variables from the outer scope, especially since in 
PHP there’s no keyword to declare your variables, which might lead to you 
accidentally capturing a variable instead of creating a new one. This isn’t as 
much of a problem with arrow functions as assignments are much less useful when 
you’re limited to a single expression.

Thus it might be best to use each when most appropriate.

@Levi, @Bob
Just out of curiosity, are variables captured by value for a specific reason?
Would there be any limitations capturing the variables by reference?

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.

Regards,
Ilija


On 5 Feb 2017, 18:52 +0100, Rowan Collins , wrote:
> On 30/01/2017 17:55, Levi Morrison wrote:
> > Here is an example of an existing closure:
> >
> > function ($x) use ($arr) {
> > return $arr[$x];
> > }
> >
> > This RFC proposes syntax and semantics to simplify this common usage to:
> >
> > fn($x) => $arr[$x]
>
> I think a lot of the disagreements and confusions on this thread come
> down to there being three fundamental views of what this new syntax is for:
>
> (a) an improved syntax for declaring closures (in the way that [$foo,
> $bar] is a shorter syntax for array($foo, $bar))
> (b) improved *semantics* for declaring closures, where you don't have to
> list the variables to be captured
> (c) a new kind of closure designed for specific use cases, with its own
> syntax and semantics
>
> These aren't mutually exclusive aims, but which of them you have in mind
> makes a big difference to what you see as "better" or "worse".
>
> Many of those starting from view (a) or (b) would like to see the syntax
> extended to closures with full bodies, and perhaps eventually become the
> most common way of declaring closures. Even if not included initially,
> they want to design the feature with that in mind. From view (c), the
> syntax is expected to exist alongside existing closures forever, just as
> we have both "for" and "while" loops.
>
> For the record, I generally come from view (c).
>
>
> On 05/02/2017 11:10, Rasmus Schultz wrote:
>
> > as long as we're introducing a new form and syntax, why make it*less* 
> > capable than
> > ordinary PHP closures?
>
> This is a good summary of the natural position from view (a) or (b) - if
> this is going to be the new way of declaring closures, we should make it
> the best way of declaring closures.
>
> If it was just about making the syntax shorter, this would be fine -
> like [...] for array(...) - but the Big Idea here is automatic capture
> of variables, and that is a lot more than just a nicety of syntax. As
> Rasmus L. has pointed out, making automatic variable capture the norm
> would be a huge change in how PHP defined variable scope.
>
> Since the comparison to JS keeps coming up, consider this: in JS, *all*
> functions capture scope greedily when they're declared; in PHP, *no*
> functions capture scope automatically; the use() clause maintains that
> rule for anonymous functions, and (in my opinion) that is a feature, not
> a mistake that needs fixing.
>
> > At the very least, I feel there should be feature
> > parity - otherwise, code in the wild is going to continue to be a strange
> > mess of one form or the other, which doesn't help with language
> > comprehension at all
>
> To be clear, from view (c), there is absolutely nothing "strange" or
> "messy" about future code having both closures and arrow-functions; they
> are different tools, to be used in different circumstances.
>
>
> On 04/02/2017 07:40, Stephen Reay wrote:
> > So, is there any argument besides "6 more characters" for*not* using the 
> > function keyword?
>
> This question presumably comes from view (b) - if it's just another way
> of declaring a function, why do we need a new keyword?
>
> From view (a), those 6 more characters are enough argument in
> themselves, because if the aim is to make it shorter, why stop early?
> From view (c), the fact that the keywords are different is a feature
> not a bug - these aren't functions in the normal sense, they are a new
> way of defining a callable, so they *should* look different.
>
>
> On 04/02/2017 20:49, Larry Garfield wrote:
> > The way I see it, the point of a short-closure is to take a simple
> > expression and wrap it into a function so that it can be plugged into
> > a function context. I 

Re: [PHP-DEV] Namespaces in Core

[Scott Arciszewski]

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 this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
​Hi,
​

> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...



I​ would definitely like to see something like this land in 7.2:

$plaintext = \Std\Sodium\box_open($ciphertext, $key, $nonce);

Is everyone willing to allow the coding standard to be updated at all,
though? I'm taking all the No votes spawned by this thread to mean "we
don't want namespaced functions ever".

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 
​

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

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 related to previous discussions about the implementation of
auto-loaders for functions and constants where we it was always a
problem on how to deal with stuff that has no use statement and no
namespace prefix, e.g.:

contains('foo');

In all cases, we know that the auto-loader does not require triggering
because the references are not ambiguous and that is what this was about.

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

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, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Namespaces in Core

[Julien Pauli]

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 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 could reasonably be namespaced as php\ast, as it
> provides
> > an AST for PHP specifically. Similarly the tokenizer extension could
> > reasonably be namespaced as php\tokenizer.
> >
> > Extensions which are not of this type should not live in the PHP
> namespace,
> > because they don't have anything specifically to do with php, apart from
> > the circumstance that they happen to be bundled at the current point in
> > time. Remember that extension may move from being bundled to being in
> PECL
> > and vice versa. If we decide to bundle the MongoDB extension with php,
> > would we rename the currently used MongoDB namespace to PHP\MongoDB? If
> we
> > decided to move it back to PECL, would the namespace go back to just
> > MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
> > anymore? Should all new extensions be written with a PHP namespace to
> > account for the possibility of the extension being bundled with PHP at a
> > later point in time (even if there are no concrete plans to do so)?
> >
> > I would answer No to these questions. The namespace MongoDB is not, as
> you
> > say, "random", it is *meaningful*. The namespace PHP is (with the
> > exceptions in the first paragraph notwithstanding) meaningless and an
> > artifact of the distribution mechanism, a mechanism which may change over
> > time.
>
> I very much agree with all of this, and would like to add, that for a
> *long* time it has been documented that PHP owns the top-level
> namespace:
> http://php.net/manual/en/userlandnaming.rules.php
>
> In any case, a discussion to namespace any existing PHP functionality
> should really wait until PHP 8 - and that means, that if we decide to
> put Sodium in PHP 7.x, it should not be namespaced out of consistenct
> *no matter what the RFC result* says.
>
>

I tend to agree with that.

Every move its time.

Namespacing PHP functions must wait for PHP 8.

But with those ideas, there is a dilema : we are going to break PECL/Sodium
users, as they now use namespaces (via PECL ext)
and would need to use functions tomorrow, to use back again namespaces
probably in several years 
Sounds not too good neither :-p


Julien.Pauli

Re: [PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

[Derick Rethans]

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.org/OoJkC
> 
> While it might be a good idea to have a way of suppressing __debugInfo 
> (I think this came up in the RFC discussion when it was added?), I 
> think debug_zval_dump should be deprecated and removed at this point.
> 
> The main thing it claims to offer over the many other variable dumps 
> is the refcount, but this has never been reliable, and is now 
> completely broken. The example in the manual recommends using 
> call-time pass-by-reference, which was removed in PHP 5.4; and in PHP 
> 7 the nature of references has changed so radically that it's not even 
> clear what the correct output would be.

It was always silly IMO. The best way to do this is to accept the 
argument's *name*, instead of the value:

https://derickrethans.nl/xdebug-2.3-xdebug-debug-zval.html

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

[Rowan Collins]

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 of suppressing __debugInfo (I think 
this came up in the RFC discussion when it was added?), I think debug_zval_dump 
should be deprecated and removed at this point.

The main thing it claims to offer over the many other variable dumps is the 
refcount, but this has never been reliable, and is now completely broken. The 
example in the manual recommends using call-time pass-by-reference, which was 
removed in PHP 5.4; and in PHP 7 the nature of references has changed so 
radically that it's not even clear what the correct output would be.

Regards,

-- 
Rowan Collins
[IMSoP]

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

[PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

[Wes]

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 __debugInfo, including with code that I've written myself (I hate
that guy).

One big problem is that once you have overriden it in a super class, you
can't revert __debugInfo back to the php's implementation easily; the
following doesn't actually do the same thing:

function __debugInfo(){ return (array)$this; }

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

Thoughts?

Re: [PHP-DEV] Namespaces in Core

[Derick Rethans]

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 could reasonably be namespaced as 
> > php\ast, as it provides an AST for PHP specifically. Similarly the 
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> 
> Agree. If we ever need namespace for mongodb extension, it should be 
> mongodb (choose capitalization to your liking), not php\mongodb - php\ 
> should be things that are really php core or specifically deal with 
> aspects of php as a language - tokenizer, syntax, etc.

It already has the MongoDB namespace btw:
http://php.net/manual/en/book.mongodb.php

And I would say that I would not agree with that namespace changing 
to (nothing) *if* it would be part of the PHP core distribution, instead 
I would choose for it to not be part of the core PHP distribution to 
avoid breaking BC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Namespaces in Core

[Derick Rethans]

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 related to PHP. For 
> > example, the php-ast extension could reasonably be namespaced as 
> > php\ast, as it provides an AST for PHP specifically. Similarly the 
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> >
> Okay, I'm pickin' up what yer layin' down.  Perhaps the question then 
> should be asked in the other direction:
> 
> Given PHP's long history and fanatical dedication to BC, should all 
> bundled/core classes/functions/constants ALWAYS remain in the root 
> namespace with a strong advisory to userspace libraries and 
> applications to use vendor namespacing (which by and large, is 
> precisely the status quo).

That would be my preference.

> If that makes sense, then that's another reason not to bring Sodium in 
> as a namespaced library of functions.

Exactly my conclusion :-)

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Namespaces in Core

[Derick Rethans]

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
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.
> 
> Extensions which are not of this type should not live in the PHP namespace,
> because they don't have anything specifically to do with php, apart from
> the circumstance that they happen to be bundled at the current point in
> time. Remember that extension may move from being bundled to being in PECL
> and vice versa. If we decide to bundle the MongoDB extension with php,
> would we rename the currently used MongoDB namespace to PHP\MongoDB? If we
> decided to move it back to PECL, would the namespace go back to just
> MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
> anymore? Should all new extensions be written with a PHP namespace to
> account for the possibility of the extension being bundled with PHP at a
> later point in time (even if there are no concrete plans to do so)?
> 
> I would answer No to these questions. The namespace MongoDB is not, as you
> say, "random", it is *meaningful*. The namespace PHP is (with the
> exceptions in the first paragraph notwithstanding) meaningless and an
> artifact of the distribution mechanism, a mechanism which may change over
> time.

I very much agree with all of this, and would like to add, that for a 
*long* time it has been documented that PHP owns the top-level 
namespace:
http://php.net/manual/en/userlandnaming.rules.php

In any case, a discussion to namespace any existing PHP functionality 
should really wait until PHP 8 - and that means, that if we decide to 
put Sodium in PHP 7.x, it should not be namespaced out of consistenct 
*no matter what the RFC result* says.

cheers,
Derick

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

Re: [PHP-DEV] Namespaces in Core

[Niklas Keller]

>
> 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 we would never require to even look at the auto-loader if
> the namespace starts with php.
>
> Obviously this could be solved for C extensions by allowing them to
> register another prefix that should not be auto-loaded: Sodium, MongoDB,
> ...
>
> Another solution could be to use pecl as their prefix. Although this
> couples it to the packaging system which might not be so nice.
>
> Any name that is tied to a company name or something else that makes
> things impossible for users to claim (Oracle, MongoDB, ...) is not a
> problem. In case of sodium that would probably be Paragon but Sodium
> might be fine too.
>
> I am not the judge here, the only thing I want is to ensure that this
> does not go unseen and that the potential of breaking something is real
> if we choose a random route like some others do. Not saying that we
> cannot do it, big ecosystems live without problems doing the same.
> However, it should be a very conscious choice and none that is taken
> lightly: meaning rules!


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

Re: [PHP-DEV] Namespaces in Core

[Tony Marston]

"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. \php\SPL\Iterator\RecursiveIteratorIterator)


Do we really need this? I mean, it's not very likely that there's
another RecursiveIteratorIterator in PHP code, and in user code it'd be
namespaced anyway... It just looks like a lot of moving things around
without any visible (at least visible to me) benefit. And given that no
code would be able to use the long name for like 10 years, and even then
why would anybody use long name if short one works In general, I
don't see a point. New exts/features - sure.


I agree with Stanislav. Everyone should remember that namespaces were only 
invented to deal with a particular problem - that of name collisions with 
user-land code or third-party libraries. It was NEVER intended to be applied 
to all core functions. Do you realise that this will break ALL existing 
code? For what benefit? Just to satisfy someone's personal preference is NOT 
enough justification.


--
Tony Marston


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

Re: [PHP-DEV] Namespaces in Core

[Tony Marston]

"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 is actually in some way related to PHP. For
example, the php-ast extension could reasonably be namespaced as
php\ast, as it provides an AST for PHP specifically. Similarly the
tokenizer extension could reasonably be namespaced as php\tokenizer.

Extensions which are not of this type should not live in the PHP
namespace, because they don't have anything specifically to do with
php, apart from the circumstance that they happen to be bundled at
the current point in time. Remember that extension may move from
being bundled to being in PECL and vice versa. If we decide to bundle
the MongoDB extension with php, would we rename the currently used
MongoDB namespace to PHP\MongoDB? If we decided to move it back to
PECL, would the namespace go back to just MongoDB? Or would it stay
PHP\MongoDB, despite not being part of PHP anymore? Should all new
extensions be written with a PHP namespace to account for the
possibility of the extension being bundled with PHP at a later point
 in time (even if there are no concrete plans to do so)?

I would answer No to these questions. The namespace MongoDB is not,
as you say, "random", it is *meaningful*. The namespace PHP is (with
 the exceptions in the first paragraph notwithstanding) meaningless
and an artifact of the distribution mechanism, a mechanism which may
 change over time.

Regards, Nikita



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


Not to me, it isn't! I have been using PHP since 2002 and I have never had 
an issue with this. Perhaps this is because I don't have weird development 
practices.



and having well known prefixes could solve the
issue since we would never require to even look at the auto-loader if
the namespace starts with php.

Obviously this could be solved for C extensions by allowing them to
register another prefix that should not be auto-loaded: Sodium, MongoDB, 
...


Another solution could be to use pecl as their prefix. Although this
couples it to the packaging system which might not be so nice.

Any name that is tied to a company name or something else that makes
things impossible for users to claim (Oracle, MongoDB, ...) is not a
problem. In case of sodium that would probably be Paragon but Sodium
might be fine too.

I am not the judge here, the only thing I want is to ensure that this
does not go unseen and that the potential of breaking something is real
if we choose a random route like some others do. Not saying that we
cannot do it, big ecosystems live without problems doing the same.
However, it should be a very conscious choice and none that is taken
lightly: meaning rules!



Introducing a new rule which breaks code that has been running happily for 
the past 15 years sounds like a bad idea to me. VERY bad.


--
Tony Marston


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

Re: [PHP-DEV] [RFC][VOTE] - list() reference assignment

[Dmitry Stogov]

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: David Walker 
Sent: Monday, February 6, 2017 8:54:27 PM
To: PHP internals
Subject: [PHP-DEV] [RFC][VOTE] - list() reference assignment

Hi all,

Having seen no further discussion I'd like to open the RFC[1] for voting.
Voting will be given just over 2 weeks ending Feb 22nd.  RFC has
implementation[2] and language spec change[3] for review.

Thanks!

--
Dave

[1] - https://wiki.php.net/rfc/list_reference_assignment
[2] - https://github.com/php/php-src/pull/2371
[3] - https://github.com/php/php-langspec/compare/master...bp1222:fix-7930

ps: my first change to the language spec, so if it's incomplete, or wrong,
advice is welcomed.

Re: [PHP-DEV] Namespaces in Core

[Lester Caine]

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 break existing conventions by 
> adding a namespace to core.
> 
> I agree with Richard that this should be decided as a general policy, rather 
> than a special exemption for this one extension, and then a fresh debate next 
> time, and next...

Once again it's about the distribution process rather than anything
fundamental to how php works? The 'linux' project PHP package is
probably the only distribution that 'bundles' a set of extensions in the
one package, as even the windows package allows individual extension
selection. Does any linux distribution actually use the php
'convention'? They all allow a different basic bundle using different
styles of control and manage all of the extensions separately.

The rfc is ... I want libsodium available on all php distributions!
That is simply not going to happen, and those distributions which have
already added namespace will follow one path, while the others will
continue to offer the current package as a 'non-namespaced' addition to
their core install as any other optional extension.

There should be a list of core functionality which everyone can 'rely'
on, and libsodium may have a place in that list, but equally users need
to be aware that it may not be present and act accordingly.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Namespaces in Core

[Rasmus Schultz]

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.

If you move everything from the root namespace into new namespaces, what
will that accomplish? You'll have an empty root namespace. But for what?

If nobody else is using the root namespace for anything, how is it
problematic for the language itself to do that?

Besides, it'll be a decade before you can actually remove the root
namespace aliases.

I don't see the point of changing this, at all.

It will lead to inconsistent code and a lot of meaningless overhead for
developers - who, ultimately, stand to gain nothing from this change.


On Mon, Feb 6, 2017 at 9:27 PM, Sara Golemon  wrote:

> On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder 
> wrote:
> > First: I like namespaces in Core but here me out!
> >
> > The PHP (case does not matter) would be the proper vendor name to put
> > Core stuff in, as far as I remember it is also reserved for PHP
> > functionality. There were also numerous discussions about providing a
> > cleaned up API there while maintaining backwards compatibility via
> > aliases and so forth in the non-namespaced Core stuff.
> >
> I've been having this same thought lately since looking at the sodium
> RFC.  Here are my thoughts, centered on the goal of having classes
> (and maybe functions?) in a \php\{extname}\ namespace hierarchy.
>
> 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. \php\SPL\Iterator\RecursiveIteratorIterator)
>
> "Aliasing" could be potentially accomplished in a few ways:
> 1. Literally just class_alias().  Put another copy of the
> zend_class_entry into the EG(class_table) under a different name.
> 2. "Auto-use": Compile-time analysis of classname: "Is it in this list
> of BC classes? Implicitly map it."
> 3. ...?
>
> I like #2 because we can raise compile-time deprecation warnings and
> we don't introduce any runtime overhead for most cases.
>
> Obviously, no removal of support for non-namespaced names until AT LEAST
> PHP 8.0
>
> This two big unanswered questions for me before I'd put this into an RFC
> are:
> 1. How to achieve BC in the best way
> 2. What to do about functions/constants? Instinct says move 'em just
> like classes.
>
> -Sara
>
> P.S. - wrt libsodium, I think THIS issue is enough for me to come down
> on the side of voting non-namespaced to avoid it being an odd-duck.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Namespaces in Core

[Rowan Collins]

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 to break 
existing use of the extension, we need to break existing conventions by adding 
a namespace to core.

I agree with Richard that this should be decided as a general policy, rather 
than a special exemption for this one extension, and then a fresh debate next 
time, and next...

Regards,

-- 
Rowan Collins
[IMSoP]

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