Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

> This needs to be agreed in the core first Meh, no. Let someone that actually worked for years and years on the specific problem to solve that, please: accumulated experience across all use-cases is the best resource you can get here, and he knows his stuff. > Is composer now the only

Re: [PHP-DEV] New HashTable implementation?

Hey, > Am 29.4.2016 um 02:04 schrieb Matt Wilmas : > > Hi all, > > Last June, it was briefly mentioned about changing PHP's string hash > function [1] (DJB33 *seems* pretty horrible, after all, as far as > collisions...). So 8 months ago I tried almost, if not, a

Re: [PHP-DEV] New HashTable implementation?

Now, after seeing Bogdan's hash optimization idea last month [2], and reading Nikita's blog post [3] again, I had some ideas I'd like to try -- assuming nobody else is planning major changes. :-) Besides Nikita, I'm addressing Dmitry and Xinchen because your names are on some minor hash items on

[PHP-DEV] New HashTable implementation?

Hi all, Last June, it was briefly mentioned about changing PHP's string hash function [1] (DJB33 *seems* pretty horrible, after all, as far as collisions...). So 8 months ago I tried almost, if not, a half-dozen of them (including Murmur3) that were simple enough to quickly toss in. The

[PHP-DEV] PHP 7.0.6 is available

Hi, The PHP development team announces the immediate availability of PHP 7.0.6. This is a security release. Several security bugs were fixed in this release, including - CVE-2016-3078 - CVE-2016-3074 All PHP 7.0 users are encouraged to upgrade to this version. For source downloads of PHP 7.0.6

[PHP-DEV] PHP 5.6.21 is available

Hello! The PHP development team announces the immediate availability of PHP 5.6.21. Several security related issues were fixed in this release. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.21 please visit our downloads page:

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

On 20.03.2016, at 22:10, David Zuelke wrote: > > On 10.03.2016, at 16:56, David Zuelke wrote: >> >>> On 08.03.2016, at 16:18, Andrea Faulds wrote: >>> >>> Hi, >>> >>> David Zuelke wrote: Is this intentional? Related to opcache's "can only

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types foronly return values

On 4/28/16 4:41 PM, Björn Larsson wrote: Can't resist jumping into this discussion, but when I first read both RFC's, I found them quite complementary. In one sense, I agree. But when it comes to the question: let's vote on the options to decide what, if anything, happens to PHP, they are

Re: [PHP-DEV] Re: ext/curl update

I seem to have created some confusion here: The reason _my_ patch for Server Push isn't merged is tests for it were requested and are blocking it. I'm not saying tests for these constants should be added. - Davey On Wed, Apr 27, 2016 at 4:15 PM, Pierrick Charron wrote: >

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

More or less right. It's easy to archive the "right" goal, if you own the both football teams. From: Tom Worster Sent: Thursday, April 28, 2016 11:40:53 PM To: Levi Morrison; Dmitry Stogov Cc: internals Subject: Re: [PHP-DEV] Re: Request

Re: Fwd: [PHP-DEV] [RFC] PHP Attributes

Hi! > I personally think that such a system should be implemented directly in > the language, like Eiffel has it. I even think that it would be easy to I think we should not try to be Haskell, Scala and Eiffel at the same time. DbC is not something most of the users of the language require and

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Levi, >From one reasonable point of view, Union and Nullable are in conflict with each other. If one prefers Union then one might argue in favor of Union over related but different proposals. When it comes to the vote, it's difficult to support both except with the argument that "I can settle for

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Hi, Can't resist jumping into this discussion, but when I first read both RFC's, I found them quite complementary. I was actually a bit tempted to combine them into one just as a writing exercise for my self (wanted to train on writing RFC's). My suggestion would be that you merge them into one

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

Fleshgrinder wrote on 28/04/2016 20:20: On 4/28/2016 8:02 PM, Rowan Collins wrote: Interesting; do you have a link to where this terminology is explained? Most of the articles I've seen just refer to "attributes", and the link you have doesn't really explain that at all, it has namespaces with

Re: Fwd: [PHP-DEV] [RFC] PHP Attributes

Is there a reason why you think that Design by Contract (DbC) should be implemented via annotations/attributes? I personally think that such a system should be implemented directly in the language, like Eiffel has it. I even think that it would be easy to add it without any BC. It might be a bit

Re: [PHP-DEV] Inline functions

I figured class methods would be a problem, especially if it were implemented at compile time as the compiler wouldn't necessarily know which class it refers to. Curious though, which part of the function call causes the performance hit? I've noticed that the number of parameters it has

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

This is not a default value (i.e. you can use = null in middle of required parameters), but defacto a nullable parameter type. Default values should and will always be changeable between functions in an inheritance tree. And while it's a tiny BC break, one can very easily fix the function from

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

On 4/28/2016 8:02 PM, Rowan Collins wrote: > Interesting; do you have a link to where this terminology is explained? > Most of the articles I've seen just refer to "attributes", and the link > you have doesn't really explain that at all, it has namespaces with > "annotation" in the name, but uses

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Levi, I provided an implementation for your RFC on February 2015, and I would be glad if your RFC was accepted that time. Bit since that time you block it in respect to "Union Types" See conversation at PR https://github.com/php/php-src/pull/1045 I would be also glad if your "Nullable Types"

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov wrote: > Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, > if you like completely different "Union Types". I don't understand; I wrote the RFC. What do you mean, "keep trying to own" it? I wrote both

Re: [PHP-DEV] Inline functions

On Thu, Apr 28, 2016 at 8:39 PM, Dominic Grostate < codekest...@googlemail.com> wrote: > That sounds wicked. I look forward to benchmarking it and seeing how its > done. > On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote: > > > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate >

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like completely different "Union Types". From: morrison.l...@gmail.com on behalf of Levi Morrison Sent: Thursday, April 28,

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins wrote: > Levi, > > Why do you need to block Dmitry's return type nullable RFC ? > > We need to move forward, that has an implementation, ready for a long > time, doesn't seem to block nullable parameter types rfc, either

Re: [PHP-DEV] Inline functions

That sounds wicked. I look forward to benchmarking it and seeing how its done. On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote: > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate > wrote: > > As I understand it, the process by which the call stack

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

PHP method compatibility rules didn't take into account default values of arguments. Adding new rule is not just a bug fix, and breaks existing code. From: Bob Weinand Sent: Thursday, April 28, 2016 9:12:54 PM To: Dmitry Stogov Cc:

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

Yeah, It's a BC break; hence I've accepted it being reverted from 7.0. I've only put the fix back in 7.1 thus. Or is it your opinion that we shall hold a formal RFC vote for a glaring bug? That sounds pretty much like a waste of everyones time to me. RFC votes IMO are for cases where we don't

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

Fleshgrinder wrote on 28/04/2016 18:33: Actually Microsoft got it exactly right and they are explaining in depth what I wrote as well. The result of an annotation is an attribute. So it is only natural to call the classes attributes. public class Customer {

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

This is a "fix", that introduces BC break. Even if I see a reason in this check, it's still a break. If you remember, we voted for almost for every BC break during PHP-7.0 development. From: Bob Weinand Sent: Thursday, April 28,

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Levi, Why do you need to block Dmitry's return type nullable RFC ? We need to move forward, that has an implementation, ready for a long time, doesn't seem to block nullable parameter types rfc, either separately or as part of unions. So, I'm not understanding why you need to hold

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

I'm not happy with the fact, that you propose two competing RFCs, support only one and trying to withdraw other competitors. From: morrison.l...@gmail.com on behalf of Levi Morrison Sent: Thursday, April 28, 2016

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

all these are good points not to commit BC breaks in hurry. From: Joe Watkins Sent: Thursday, April 28, 2016 8:41:34 PM To: Bob Weinand Cc: Dmitry Stogov; Anatol Belski; internals; Levi Morrison Subject: Re: [PHP-DEV] Request to withdraw

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov wrote: > your Nullable RFC doesn't propose working implementation. > > > From: morrison.l...@gmail.com on behalf of Levi > Morrison > Sent:

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

> Am 28.04.2016 um 19:28 schrieb Dmitry Stogov : > > hi Joe, > > > No problem, great it's fixed before 7.0.6 release. > > I think this change might be introduced only together with nullable or union > types. > > Otherwise it makes a problem, described by Levi, that doesn't

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

your Nullable RFC doesn't propose working implementation. From: morrison.l...@gmail.com on behalf of Levi Morrison Sent: Thursday, April 28, 2016 8:39:03 PM To: Dmitry Stogov Cc: internals; Tom Worster Subject:

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

On 4/27/2016 11:36 PM, Lester Caine wrote: > To add to your list ... > https://www.phpdoc.org/docs/latest/guides/docblocks.html > > The glossary entry is rather bare, but I would dispute THEIR statement - > "but also influences the way the application behaves." > > In my book, these comment

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

The problem is as Levi explained though Bob, don't we actually require nullables/unions for that case ? Maybe we can move forward now, confident that by the time 7.1 is released we will have one of those things ? The problems with that are, the RFC's for unions/intersections don't match the

Re: [PHP-DEV] Inline functions

On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate wrote: > As I understand it, the process by which the call stack is updated and > scope changed, is quite expensive. And from tests I can see that function > calls do actually add a not insignificant overhead to

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov wrote: > Thanks for catching the BC break. > Fortunately, we didn't release 7.0.6 with this problem. > > I see some sense in introducing that check, but changing behaviour requires > RFC and definitely not allowed in minor

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov : > > Hi, > > The BC break in PHP-7.0 was introduced by commit > ee9a78a033696ff9546fb1dbfecd28f20477b511 > > Author: Joe Watkins > Date: Mon Mar 28 11:54:25 2016 +0100 > > Late, there were few more commits

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

On 4/28/2016 11:36 AM, Rowan Collins wrote: > While I personally prefer the name "annotations", I don't see it as > particularly urgent, or nearly as clear-cut as you claim. > That's okay and why we are discussing things. ;) On 4/28/2016 11:36 AM, Rowan Collins wrote: > I clicked through on

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

hi Joe, No problem, great it's fixed before 7.0.6 release. I think this change might be introduced only together with nullable or union types. Otherwise it makes a problem, described by Levi, that doesn't allow running the same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Evening Dmitry, This was discussed at length with bob, and I think nikita also, it seemed like a bug fix rather than a feature. Happy for it to be moved into 7.1 ... sorry for dropping the ball there ... Cheers Joe On Thu, Apr 28, 2016 at 6:07 PM, Dmitry Stogov wrote: >

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Thanks for catching the BC break. Fortunately, we didn't release 7.0.6 with this problem. I see some sense in introducing that check, but changing behaviour requires RFC and definitely not allowed in minor versions. I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types It

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

Hi, The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511 Author: Joe Watkins Date: Mon Mar 28 11:54:25 2016 +0100 Late, there were few more commits that changed and moved the problematic code. Anatol, I think we should revert this

Re: [PHP-DEV] [RFC] Intersection Types

Bob Weinand wrote on 28/04/2016 16:49: Regarding your suggestion, $foo instanceof Foo & Bar is conflicting with bitwise and here. Anyway, you already can $foo instanceof Foo && $foo instanceof Bar. Which is IMO just as easy, not conflicting and more flexible. It's a shame that that's so

[PHP-DEV] Request to withdraw RFC's for nullable types for only return values

I have discovered through a [bug report][1] a case where having explicitly nullable parameters would be of value. You can theoretically change the default value in a sub-type, but in this case moving away from the default value of null breaks because the subtype no longer permits null. It is

Re: [PHP-DEV] [RFC] Intersection Types

> Am 28.4.2016 um 17:11 schrieb guilhermebla...@gmail.com: > > Nice! > > I've read the RFC and there's only one missing thing that is either > undocumented or missed during patch creation: instanceof. > I'd be amazing if we could do: $foo instanceof Foo & Bar > > Cheers, > > On Thu, Apr 28,

Re: [PHP-DEV] [RFC] Intersection Types

Nice! I've read the RFC and there's only one missing thing that is either undocumented or missed during patch creation: instanceof. I'd be amazing if we could do: $foo instanceof Foo & Bar Cheers, On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio wrote: > On Thu, Apr 28,

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-04-28

Results for project PHP master, build date 2016-04-28 15:53:03+03:00 commit: 6499162 previous commit:e88c71d revision date: 2016-04-28 04:13:34+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

Lester Caine wrote on 28/04/2016 08:21: On 28/04/16 06:35, Marco Pivetta wrote: This is what Mike van Riel was working on with PSR-5. Work has been suspended atm, but I'd still go look at that first. Sorry but php-fig is not PHP and sme of the 'standards' created there are at odds with the

Re: [PHP-DEV] [RFC] Intersection Types

On Thu, Apr 28, 2016 at 4:54 AM, Levi Morrison wrote: > Internals, > > As alluded to last week I have another RFC for improving the type > system: [intersection types][1]. > > It allows parameters to define multiple type constraints that must be > satisfied. Common combinations of

[PHP-DEV] Inline functions

Something in Dmitry's attribute RFC caught my attention. There is an example implying inline functions indicated by an attribute. I know that was only a potential use case for an extension. But it made me wonder how much that could improve PHPs performance if we actually had it. As I understand

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On 28/04/16 06:35, Marco Pivetta wrote: > This is what Mike van Riel was working on with PSR-5. Work has been > suspended atm, but I'd still go look at that first. Sorry but php-fig is not PHP and sme of the 'standards' created there are at odds with the preferred practices in the PHP code ...