Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

Hi Larry, On Apr 30, 2016 6:48 AM, "Larry Garfield" wrote: > > Most of the examples that have been given so far are either trivial boolean flags or data validation rules to be evaled. In practice, very little of Drupal's use of annotations in Drupal 8 fit either

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator I think this takes the syntax too much towards Perl 6 direction. There is a lot of fun in inventing cool signs like |>

Re: [PHP-DEV] [RFC] Pipe Operator

Hey, to me recursion and pipe operator looks really hard to read, I guess this is faster and better readable: foreach (scandir($arg) as $x) { if ($x == '.' || $x == '..') { continue; } $x = $arg . '/' . $x; // inline getFileArg ... $allFiles[] = $x; } Regards Thomas Bob Weinand

Re: [PHP-DEV] [RFC] Pipe Operator

On 04/29/2016 06:37 PM, Bob Weinand wrote: Hey, Am 29.04.2016 um 21:58 schrieb Sara Golemon : This is one of my favorites out of HackLang. It's pure syntactic sugar, but it goes a long way towards improving readability. https://wiki.php.net/rfc/pipe-operator Thanks for

[PHP-DEV] [RFC][Discussion] Add curl_multi_errno(), curl_share_errno() and curl_share_strerror()

Hi Internals, I would like to introduce 3 new functions to ext/curl - curl_multi_errno() - curl_share_errno() - curl_share_strerror() With those 3 functions added, it will now be possible to get any error that curl detect on any of the curl resource types and the error message associated to it.

[PHP-DEV] Attributes/Annotations Case Study: Drupal

Most of the examples that have been given so far are either trivial boolean flags or data validation rules to be evaled. In practice, very little of Drupal's use of annotations in Drupal 8 fit either category. Rather, they're used primarily as, in essence, a serialized metadata object

Re: [PHP-DEV] [RFC] Pipe Operator

Hey, > Am 29.04.2016 um 21:58 schrieb Sara Golemon : > > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator Thanks for proposing, so that I am able to show

[PHP-DEV] [RFC] [VOTE] Octal Interpolation Overflow

Voting has opened for https://wiki.php.net/rfc/octal.overload-checking Vote YES to raise a compile time warning when octal values greater than \377 are used. Vote NO to continue ignoring the overflow. Regardless of outcome, the value interpolated into the string will retain "wrap-around"

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

Hi Davey, > -Original Message- > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey > Shafik > Sent: Thursday, April 28, 2016 11:30 PM > To: Pierrick Charron > Cc: Anatol Belski ; PHP internals >

[PHP-DEV] [RFC] Pipe Operator

This is one of my favorites out of HackLang. It's pure syntactic sugar, but it goes a long way towards improving readability. https://wiki.php.net/rfc/pipe-operator -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Forbid $this being null in instance methods

On Fri, Apr 29, 2016 at 9:10 PM, Stanislav Malyshev wrote: > Hi! > > > I'd like to submit a small RFC for your consideration, which ensures > > something that really ought to be a given already: If you use $this in an > > instance method, you should actually get a $this (and

Re: [PHP-DEV] [RFC] Forbid $this being null in instance methods

Hi! > I'd like to submit a small RFC for your consideration, which ensures > something that really ought to be a given already: If you use $this in an > instance method, you should actually get a $this (and not NULL). > > https://wiki.php.net/rfc/forbid_null_this_in_methods > > As this is

Re: [PHP-DEV] [RFC:generics]

Yes this makes perfect sense now. On 29 Apr 2016 6:44 p.m., "Mathieu Rochette" wrote: > > > On 04/29/2016 06:02 PM, Rowan Collins wrote: > > Hi Dominic, > > > > Sorry, I think this may have got sent too early by mistake; please > > ignore the duplicate! > > > > Also, it's

Re: [PHP-DEV] [RFC:generics]

On 04/29/2016 06:02 PM, Rowan Collins wrote: > Hi Dominic, > > Sorry, I think this may have got sent too early by mistake; please > ignore the duplicate! > > Also, it's crossed in the post with your next message, but I'll send > it anyway, in case it helps anyone understand. > > > Dominic

Re: [PHP-DEV] [RFC] Forbid $this being null in instance methods

On Fri, Apr 29, 2016 at 1:12 PM, Nikita Popov wrote: > Hi internals! > > I'd like to submit a small RFC for your consideration, which ensures > something that really ought to be a given already: If you use $this in an > instance method, you should actually get a $this (and

[PHP-DEV] [RFC] Forbid $this being null in instance methods

Hi internals! I'd like to submit a small RFC for your consideration, which ensures something that really ought to be a given already: If you use $this in an instance method, you should actually get a $this (and not NULL). https://wiki.php.net/rfc/forbid_null_this_in_methods As this is

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

Lester Caine wrote on 29/04/2016 17:50: On 29/04/16 16:42, Rowan Collins wrote: function foo($a) { if ( $a < 42 ) { throw new Exception; } // Must not reach The Answer ... } vs <> // Must not reach The Answer function foo($a) { ... } The first version is my current code base,

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

On Fri, Apr 29, 2016 at 10:50 AM, Lester Caine wrote: > On 29/04/16 16:42, Rowan Collins wrote: > > function foo($a) { > > if ( $a < 42 ) { throw new Exception; } // Must not reach The Answer > > ... > > } > > > > vs > > > > <> // Must not reach The Answer > >

Re: [PHP-DEV] [RFC:generics]

Dominic Grostate wrote on 29/04/2016 17:45: This means then that to use a subtype for the type argument, it is safe for the function to READ the argument, but unsafe to WRITE to it. Conversely. If the function accepted List, but was theoretically given List, WRITING would be safe, but

Re: [PHP-DEV] New HashTable implementation?

On Thu, 2016-04-28 at 19:04 -0500, Matt Wilmas wrote: > 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

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

On 29/04/16 16:42, Rowan Collins wrote: > function foo($a) { > if ( $a < 42 ) { throw new Exception; } // Must not reach The Answer > ... > } > > vs > > <> // Must not reach The Answer > function foo($a) { ... } The first version is my current code base, although it's unlikely to

Re: [PHP-DEV] [RFC:generics]

This means then that to use a subtype for the type argument, it is safe for the function to READ the argument, but unsafe to WRITE to it. Conversely. If the function accepted List, but was theoretically given List, WRITING would be safe, but READING wouldn't. Given this, it doesn't matter how

Re: [PHP-DEV] [RFC:generics]

On Sat, Apr 30, 2016 at 12:26 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Wrong. This is documented here > https://docs.oracle.com/javase/tutorial/java/generics/upperBounded.html > and specifically states: > > To write the method that works on lists of Number and the

Re: [PHP-DEV] [RFC:generics]

Dominic Grostate wrote on 29/04/2016 16:59: After reading your email again, I find myself agreeing. This is because I don't consider List to be a subtype of List. LinkedList would be a subtype of List, but inheritance doesn't really extend any further beyond that, for the reason you have

Re: [PHP-DEV] [RFC:generics]

Hi Dominic, Sorry, I think this may have got sent too early by mistake; please ignore the duplicate! Also, it's crossed in the post with your next message, but I'll send it anyway, in case it helps anyone understand. Dominic Grostate wrote on 29/04/2016 16:45: It's not insane, it's liskov

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

On Fri, Apr 29, 2016 at 9:18 AM, Lester Caine wrote: > On 29/04/16 14:51, Rowan Collins wrote: > > Lester Caine wrote on 29/04/2016 14:18: > >> But where will annotations like @range(0,110) fit in the new model? > >> Along with the likes of '@notnull' and similar annotations

Re: [PHP-DEV] [RFC:generics]

After reading your email again, I find myself agreeing. This is because I don't consider List to be a subtype of List. LinkedList would be a subtype of List, but inheritance doesn't really extend any further beyond that, for the reason you have illustrated. The example you gave is similar to

Re: [PHP-DEV] [RFC:generics]

Dominic Grostate wrote on 29/04/2016 16:45: It's not insane, it's liskov substitution. But that is an insane example, typical of Java to create a type that extends it's parent by adding value constraints.. directly violating the principle. Read the example again, and translate it into

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

Lester, I understand that IDEs are doing a nice job over the toolset already created around documentation. That's what phpdoc and friends do. Also, if you take PHPStorm, it also helps you add Doctrine annotations with ease. But this is just one IDE, and that's what they're supposed to do; help

Re: [PHP-DEV] [RFC:generics]

It's not insane, it's liskov substitution. But that is an insane example, typical of Java to create a type that extends it's parent by adding value constraints.. directly violating the principle. On 29 Apr 2016 4:22 p.m., "Rowan Collins" wrote: guilhermebla...@gmail.com

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

Hi Lester, Lester Caine wrote on 29/04/2016 16:18: I think that is part of the problem here. IDE's are currently making quite good use of existing annotation text, but if they have to be switched to modes where some other option takes priority then once again all the code has to be reworked

Re: [PHP-DEV] [RFC:generics]

guilhermebla...@gmail.com wrote on 29/04/2016 15:26: You can add subtypes of A to a List in Java. What List >means is that the list itself may be a list of any type, provided that type >is compatible with A. So if B extends A, List is compatible with Listextends A>, and when reading items you

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

On 29/04/16 14:51, Rowan Collins wrote: > Lester Caine wrote on 29/04/2016 14:18: >> But where will annotations like @range(0,110) fit in the new model? >> Along with the likes of '@notnull' and similar annotations that are also >> currently being planned to be spread around the rest of the code?

Re: [PHP-DEV] [RFC:generics]

Sorry for top-posting... it looks like GMail top-posts everything that doesn't have a reply character right before the inherited (replied email), which i just did. On Fri, Apr 29, 2016 at 10:26 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > > On Fri, Apr 29, 2016 at 4:55

Re: [PHP-DEV] [RFC:generics]

On Fri, Apr 29, 2016 at 4:55 AM, Jesse Schalken wrote: > > > On Wed, Apr 27, 2016 at 6:50 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> Hi all, >> >> Yesterday I spent a considerable 2h talking about Generics in Doctrine >> channel. >> We

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

Lester Caine wrote on 29/04/2016 14:18: But where will annotations like @range(0,110) fit in the new model? Along with the likes of '@notnull' and similar annotations that are also currently being planned to be spread around the rest of the code? If a variable is defined via the metadata as 'not

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

On 29/04/16 13:49, Benjamin Eberlei wrote: > Lester, nobody wants to move phpdoc out of the *doc* comment. Its still > documentation. It will stay,. > > We want to move the "annotations" out of the docblocks that are evaluated > at runtime for configuration. Thats two different things. That is

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

On Fri, Apr 29, 2016 at 2:36 PM, Rowan Collins wrote: > Lester Caine wrote on 29/04/2016 13:02: > >> In my book this is DIRECTLY relevant to the current discussion! >> >> We have been adding attributes via docBloc annotation since PHP4 days. >> This has partly been

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

Lester Caine wrote on 29/04/2016 13:02: In my book this is DIRECTLY relevant to the current discussion! We have been adding attributes via docBloc annotation since PHP4 days. This has partly been accepted as the default way of doing it and phpDoc was originally part of the PEAR support

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

On 29/04/16 10:42, Rowan Collins wrote: > Lester Caine wrote on 29/04/2016 10:17: >> And it would be nice if you actually checked out just how phpdocumentor1 >> worked and explain why I can't produce >> http://lsces.org.uk/bitweaverdocsPHP/index.html with phpDocumentor2 ... > > The simple fact

[PHP-DEV] PHP 5.5.35 is available

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

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-04-29

Results for project PHP master, build date 2016-04-29 06:29:29+03:00 commit: 153b27d previous commit:6499162 revision date: 2016-04-28 20:10:28+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] RE: New HashTable implementation?

> -Original Message- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Friday, April 29, 2016 10:52 AM > To: Matt Wilmas ; internals@lists.php.net > Cc: Nikita Popov ; Xinchen Hui > Subject: [PHP-DEV] Re: New

Re: [PHP-DEV] Forbid dynamic calls to scope introspection/modification functions

Hi Nikita, We already discussed this, and I told that I don't have strong opinion about this change. >From one pint of view, your are going to disable some legal code patterns. function foo() { $f = "func_num_args"; $n = $f(); } array_map("export", [$_GET, $_POST]); On the other hand,

RE: [PHP-DEV] Lazy keys comparison during hash lookups

> -Original Message- > From: Matt Wilmas [mailto:php_li...@realplain.com] > Sent: Wednesday, April 27, 2016 5:44 PM > To: Andone, Bogdan ; 'Nikita Popov' > > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Lazy keys comparison during

[PHP-DEV] Forbid dynamic calls to scope introspection/modification functions

Hi internals! Welcome to another edition of "crazy PHP edge-cases you don't want to know about". I'd like to introduce a restriction that forbids performing dynamic calls to scope introspection and modification functions. "Dynamic calls" here means things like $fn(), call_user_func($fn) and

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

Lester Caine wrote on 29/04/2016 10:17: And it would be nice if you actually checked out just how phpdocumentor1 worked and explain why I can't produce http://lsces.org.uk/bitweaverdocsPHP/index.html with phpDocumentor2 ... The simple fact is that this is completely off-topic for this list.

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

On 29/04/16 09:41, Marco Pivetta wrote: > Sorry if you didn't spend the last 6+ years of your free time > > (yes, that is an import) maintaining an open-source project focused on > annotations-based

Re: [PHP-DEV] [RFC:generics]

On Wed, Apr 27, 2016 at 6:50 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Hi all, > > Yesterday I spent a considerable 2h talking about Generics in Doctrine > channel. > We discussed the specifics of each boundary that PHP's implementation could > take advantage. Here are

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

Hey Lester, Sorry if you didn't spend the last 6+ years of your free time (yes, that is an import) maintaining an open-source project focused on annotations-based documentation. Marco Pivetta

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

On 29/04/16 03:20, Marco Pivetta wrote: > > 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

[PHP-DEV] Re: New HashTable implementation?

Hi Matt, I also tried different hash functions (including mumur3) and came to similar result. Faster function but more hash collisions. Actually these collisions occurs not because of different hash values, but because of small hash array size. Also the way we transform hash value into hash

[PHP-DEV] Re: New HashTable implementation?

On Fri, Apr 29, 2016 at 2:04 AM, Matt Wilmas wrote: > 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?

On Fri, Apr 29, 2016 at 9:04 AM, Matt Wilmas wrote: > 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

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

Morning David, To confirm it was something to do with opcache, I removed opcache from the source tree: krakjoe@fiji:/usr/src/php-src$ ./configure --disable-all | grep static checking if cc static flag -static works... yes checking whether to build static libraries... yes