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

[Marco Pivetta]

 > 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 supported installation tool?

For pretty much most projects, yes. In this case, you can still use PEAR
(not sure for how much more, though) or a PHAR download:
https://www.phpdoc.org/docs/latest/getting-started/installing.html


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 28 April 2016 at 09:21, Lester Caine  wrote:

> 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 ... which is
> one reason I see that some of the developments have been thankfully
> suspended. The changes to phpdocumentor are also at odds with core
> practices and that is why I am putting my hand up here. This needs to be
> agreed in the core first and personally I'd prefer that this annotation
> practice was the primary one, and adding hard coded options remained
> optional not enabled by default.
>
> Is composer now the only supported installation tool? Even phpdocumentor
> installer advises using other methods because of the mess composer
> creates if you are installing more than one 'application', but the only
> supported method for using php-annotations is via composer ... creating
> it's own problems when trying to add back code that existed in the past.
>
> --
> 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] New HashTable implementation?

[Bob Weinand]

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 half-dozen of
> them (including Murmur3) that were simple enough to quickly toss in.
> 
> The result?  In all cases, I believe, fewer instructions (in zend_hash_find,
> and the hashing function), BUT also a slight-to-small increase in cache
> misses in Wordpress and other scripts...
> 
> And in a test filling an array with a million "string_$i" keys (high
> collision pattern for DJB33?), the speed was halved by the *huge* cache miss
> increase. :-/
> 
> I couldn't quite understand what was happening, where, if there were fewer
> collisions...  Misses all spread out in the hash-array?
> 
> So there didn't seem to be anything useful to gain there.
> 
> 
> Now, after seeing Bogdan's hash optimization idea last month [2], and
> reading Nikita's blog post 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 the 7.1 ideas wiki [4].
> 
> I'm thinking of a Robin Hood implementation with Universal hashing [5] (of
> int keys and the string hashes).  I haven't touched any code yet, but think
> I've worked out all the details in my head, and am ready to take a stab at
> it.  I think it's fairly simple to get the basics working; and when I see
> how that goes, I can do the additional optimizations I have in mind that it
> allows (including reduced memory, on 64-bit at least).
> 
> Question: Can I use zval.u1.v.reserved ?  I guess I'll find out otherwise.
> :-O

No, not really. zval.u1 gets typically overwritten on each type assignment.
(As type assigns typically happen via 32 bit type_info field directly for 
performance reasons.)
Eventually you may find a way to split up u2 in an useful way?

> 
> The string hash function itself is really a separate thing [6], but fasthash
> [7] (not to be confused with "superfast") looks like a good one that I
> missed before...  After thinking about things, I think we could even
> keep/use a 64-bit hash on 32-bit arch.
> 
> 
> Well, just wanted to mention it first if anyone has a comment. :-)  Should
> be interesting, but no idea how it'll perform (lookups should be very, very
> fast (upsizing also); but cache factors and inserts/deletes are wildcards).
> Wish me luck!?

Good luck! :-)

> 
> Thanks,
> Matt
> 
> [1] https://marc.info/?l=php-internals=143444845304138=2
> [2] https://marc.info/?t=14574424811=1=2
> [4] https://wiki.php.net/php-7.1-ideas
> [5] https://en.wikipedia.org/wiki/Universal_hashing
> [6] https://github.com/rurban/smhasher
> [7] https://github.com/rurban/smhasher/blob/master/doc/fasthash64



Bob

Re: [PHP-DEV] New HashTable implementation?

[Matt Wilmas]

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 the 7.1 ideas wiki [4].


My ISP's stupid mail server wouldn't allow the link to Nikita's blog. 
Trying again.


[3] nikic.github.io/2014/12/22/PHPs-new-hashtable-implementation.html

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

[PHP-DEV] New HashTable implementation?

[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 half-dozen of
them (including Murmur3) that were simple enough to quickly toss in.

The result?  In all cases, I believe, fewer instructions (in zend_hash_find,
and the hashing function), BUT also a slight-to-small increase in cache
misses in Wordpress and other scripts...

And in a test filling an array with a million "string_$i" keys (high
collision pattern for DJB33?), the speed was halved by the *huge* cache miss
increase. :-/

I couldn't quite understand what was happening, where, if there were fewer
collisions...  Misses all spread out in the hash-array?

So there didn't seem to be anything useful to gain there.


Now, after seeing Bogdan's hash optimization idea last month [2], and
reading Nikita's blog post 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 the 7.1 ideas wiki [4].

I'm thinking of a Robin Hood implementation with Universal hashing [5] (of
int keys and the string hashes).  I haven't touched any code yet, but think
I've worked out all the details in my head, and am ready to take a stab at
it.  I think it's fairly simple to get the basics working; and when I see
how that goes, I can do the additional optimizations I have in mind that it
allows (including reduced memory, on 64-bit at least).

Question: Can I use zval.u1.v.reserved ?  I guess I'll find out otherwise.
:-O


The string hash function itself is really a separate thing [6], but fasthash
[7] (not to be confused with "superfast") looks like a good one that I
missed before...  After thinking about things, I think we could even
keep/use a 64-bit hash on 32-bit arch.


Well, just wanted to mention it first if anyone has a comment. :-)  Should
be interesting, but no idea how it'll perform (lookups should be very, very
fast (upsizing also); but cache factors and inserts/deletes are wildcards).
Wish me luck!?


Thanks,
Matt

[1] https://marc.info/?l=php-internals=143444845304138=2
[2] https://marc.info/?t=14574424811=1=2
[4] https://wiki.php.net/php-7.1-ideas
[5] https://en.wikipedia.org/wiki/Universal_hashing
[6] https://github.com/rurban/smhasher
[7] https://github.com/rurban/smhasher/blob/master/doc/fasthash64


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

[PHP-DEV] PHP 7.0.6 is available

[Anatol Belski]

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 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-7.php#7.0.6


Below is the verification information for the downloads:

php-7.0.6.tar.bz2
SHA256 hash:
14ddf192a9965c858c1e742a61456be2f34a4db87556172c0d76f08de96329b7
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIlNwAAoJELyqMOqcDVdjRdgIAMaUa6oDrrCipgF1faK8axyy
Rtr+Z+RYW/eFKZpNSwrXWX91YophYHfsfrlgMCj6s2hOMusZAhlO/LmzjN26Hckl
fzY6nj+wkY/xZwJ/xegIMutu7kG6Uu+rfo0mewWZUCyZZwkvK/59ZOuaMfmKbCCh
pAhoXwEFYap2vEhhOrKeEcf9IKsqLC8DxSHtEP0CbDHbKy5cejdgD2LOU5kIFzrh
DGE9HL5mr8ot2ZxQdxEIyIBwZ+hStD8zd82q+De6nAoNoiB9f3D2XjyCRb0xWyOz
BdDyAarcmuSphFiGBkbXU65/bGyBVBTGdu74GXKjFwTPHud15Qzbg/HckslQ/vM=
=KL16
-END PGP SIGNATURE-


php-7.0.6.tar.gz
SHA256 hash:
f6b47cb3e02530d96787ae5c7888aefbd1db6ae4164d68b88808ee6f4da94277
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIlN0AAoJELyqMOqcDVdj7qEIAJvBHIxqf3yAYQj4pQ8JBDNt
gwemNyQAVu3939YgTdflJZAEnHNypiyso+W4WIBuZsIyImR54zj/b6SdK1ocwbQR
0sKqLtHmhk5BOO3rFKjgSyCOmK92mn/Z505kbduT4i5y48scZ/jOcnUUddwsRgHV
V0YkD83kKZcXoz7SBRDTN7xgc826RC45TYKuax6F69nN6Y497zfvkjUROH50pypy
IMH4D9gXf0yR8ZYOU2D4D4ni65S6gq22xJZgfP/WbbcR52GmD38mQGYwfjuA9UMU
seiOyM9Iu/ircb338pXJCsnr13HwuvHcvNRE5Oy0sQRKftqqRk5UERIMXJIazuk=
=qdza
-END PGP SIGNATURE-


php-7.0.6.tar.xz
SHA256 hash:
1b237a9455e5476a425dbb9d99966bad68107747c601958cb9558a7fb49ab419
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIlN2AAoJELyqMOqcDVdjOR8IAMSdhasa06V8r4bX6+xbXHF2
KFH3XL5VFRp6f9TbSI68WRS34ZY+McMvPDqnCUIWx53es89nW3ShbGpvoBDfCfRF
tx/MlQDUemqkhX/Fqxdlysl3Kz7nK1SPP2rvLS50RE5++a4srnGpys7c331kYfeo
WHXfozdZSv+uuhAoQy4E+SK6h7NhLrE5+Pr6lZyr6lEkT8C4ji2AvoZHur1LHcKk
XyuL0aPi/vdnAEQSs2hxaKpAf6+bLdnDcB4SnqidPpU2nYmhgSs0hQ8x/4H+3XL0
FmiBVxll71MvfcWXHeWMFM/iqdwwF3xk4xpLE50nOnpgaUsN7MvII4MTiM8my2o=
=MndQ
-END PGP SIGNATURE-


Regards,
Anatol Belski and Ferenc Kovacs


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

[PHP-DEV] PHP 5.6.21 is available

[Ferenc Kovacs]

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:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.21

To verify the downloads, you can use the following information:

php-5.6.21.tar.bz2
SHA256 hash:
b4ed7ab574b689fd6d6494fde954826c06efc85c505e017b8d776c7c7f479590
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIWBaAAoJEMK/C8Qzz8izzusIAKqR1O63BCrkmL2M4BEtz9on
HHFAR8nGRK8sqq74mwvlOjNI+bS3QRwkOpGpS1OKnPOc8qcjLRh/LEqKjB32PXx8
jcrLO3eJZyhXqaAkjq+2mDjMeOHKrV+tyFoHAhB/bMTXW8q26mZvi7NS30YyBHB2
9aAK4fnuK7f+ERGS9M6652j1kXw07Rr9963eHQ+bgFLCykdiO4GYfkOpxlfhij2+
EdPpcFYp3zvRLozrs0Fm8gOUwjOXhb9Y9v53mzFNOH1kPPbWk8U12AYPSlaLNpW5
cs7gYVJ7ZCpd9rhJ/Lm/AENpvKffuJ1SibWjkkCxVC+IVcmH4ry8ecc9uu4qR68=
=Muah
-END PGP SIGNATURE-

php-5.6.21.tar.gz
SHA256 hash:
5997668c1f6f2d86a59cf75cc86b4a94687884614dec481fad7e13a76b70fcd5
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIWBoAAoJEMK/C8Qzz8izuCIIAJu69PXsjiFme0Un0SFH9Yzi
DmXuV13DDZiA+KXBGAFYyCR5YZaPFJLiBnMsVmU2gqFsdn2C2udfDiC8S0B/CLfT
MhdUcA83NmtIfGmzaSRuwWEiVPLnforhTom+221n1yuesR144rEo7w/0fVXvJoAT
6xq0OWWhe5zue5snKrqaU+c8cY0yuu+jWJQTLgQpYpmubU1S1FcvU92NQBYqUksa
Vx6DkeZieTCYrTNRM+BHp9JHE8kWs4Z8oezB6emQgrjWaGiw19sWIKx9b4ZbDzJt
YimpskCkBF/ulIKG2qOw4nVeT3EvbYmg+iFraEgLRGMgw2mIxSr5G00HVwmUsCw=
=pVhm
-END PGP SIGNATURE-

php-5.6.21.tar.xz
SHA256 hash:
566ff1a486cb0485ed477a91ea292423f77a58671270ff73b74e67e3ce7084f9
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIWBvAAoJEMK/C8Qzz8izxLMIAKAPFnuEgbgBVmVK5wrZg8NG
Kd9e8qq+8QC/7RPUhjr2/6ySRP0quRAp/nK2ncjWDVavgu59GVgoap9iIV5EZzwo
/MurdkxhxPWG6qwnG36+sqfEBii5JGuKpwFOypvrau2tBH8A7CAvrDwCgkR5gPfx
wjJjK6IuxSaI7xPXa8pKdK4TKUyNEwBZ6AGl2tt2Ql3x0FM+2nBFcpKZglIp0F7P
CXpj3Hfm1o6kT36mHGiXDTlVaba31vME/KQGTFB+90mLvbPy4Zd5mUBNcdKP/Avz
u8A7OynEzeD+e5+zTul7k9Zv/IghslR0hukjuPQ+HHBlHX2QuT3FI5Z+kTpFqw0=
=Bqqk
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

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

[David Zuelke]

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 be built shared" 
 status? But why would that trigger static builds? Or is it a bug?
>>> 
>>> While we're at it, why is Opcache still built as shared? Does something 
>>> prevent it being statically-linked?
>> 
>> I remember something about PCRE and whether or not that's linked statically 
>> or not. Can't find it right now.
>> 
>> Either way, it'd be great if someone in-the-know could chime in on this 
>> matter ;)
> 
> Just a little *bump*... anyone got any idea here?
> 
> Thanks!

And another *bump*... anyone from Zend maybe?


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

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

[Tom Worster]

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 
options with important differences. There's no way I can see to organize 
the vote that would be fair to everyone.


For example, I prefer nullable returns only. I could settle for nullable 
hints/returns (NRH) as a second choice but I would prefer to make no 
change at all over union types. That being the case, I would want the 
voting to be structured in one specific way.



> 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 and put
> it into vote quickly, maybe having you both as authors or one of
> you taking the lead?

I considered how this might work but I can't imagine how combining RFCs 
makes it easier. If more than one yes/no voting option is presented in 
one RFC, it's likely to be more confusing than voting on more than one RFC.


Tom


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

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

[Davey Shafik]

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:

> Sorry for the 2 mails but I forgot to give you the URL :
>
> https://github.com/php/php-src/pull/1890/files
>
> On 27 April 2016 at 19:14, Pierrick Charron  wrote:
>
>> Hi Anatol,
>>
>> I created a new patch from the one first published but this time this one
>> target 7.0 and only expose new constants to that do not require any logic
>> on the extension side.
>> These constants are just exposed if they are available in the version
>> installed and are bridge in the curl_setop function.
>>
>> If that's OK I'll commit this on 7.0 and merge it also on master. Then
>> I'll work on adding new things that require logic and clean those for 7.1
>> and add tests if possible.
>>
>> Regards
>> Pierrick
>>
>> On 27 April 2016 at 12:55, Anatol Belski  wrote:
>>
>>>
>>>
>>> > -Original Message-
>>> > From: pierr...@webstart.fr [mailto:pierr...@webstart.fr] On Behalf Of
>>> Pierrick
>>> > Charron
>>> > Sent: Wednesday, April 27, 2016 6:20 PM
>>> > To: Anatol Belski 
>>> > Cc: Davey Shafik ; PHP internals <
>>> internals@lists.php.net>;
>>> > paj...@php.net
>>> > Subject: Re: [PHP-DEV] Re: ext/curl update
>>> >
>>> > Yep I'll check if I can add some test that could be easy to implement
>>> using
>>> > curl_easy_getinfo or using the php local server. Otherwise not sure we
>>> could
>>> > easily compile PHP with all those libcurl versions...
>>> >
>>> >
>>> > On 27 April 2016 at 11:37, Anatol Belski >> >  > wrote:
>>> >
>>> >
>>> >   Hi,
>>> >
>>> >   > -Original Message-
>>> >   > From: pierr...@webstart.fr 
>>> > [mailto:pierr...@webstart.fr  ] On
>>> Behalf Of
>>> > Pierrick
>>> >   > Charron
>>> >   > Sent: Wednesday, April 27, 2016 2:20 PM
>>> >   > To: Anatol Belski >> >  >
>>> >   > Cc: Davey Shafik  >; PHP
>>> > internals  >;
>>> >   > paj...@php.net 
>>> >   > Subject: Re: [PHP-DEV] Re: ext/curl update
>>> >   >
>>> >   > I agree, but I don't really now how I could test those things
>>> since they
>>> > almost all
>>> >   > of the time only affect how libcurl will handle the
>>> request/cache and
>>> > we have no
>>> >   > way to retrieve options like curl_easy_getopt or something
>>> similar.
>>> >   >
>>> >   > On 27 April 2016 at 02:46, Anatol Belski <
>>> anatol@belski.net
>>> > 
>>> >   > 
>>> > >
>>> > wrote:
>>> >   >
>>> >   >
>>> >   >   Hi,
>>> >   >
>>> >   >   > -Original Message-
>>> >   >   > From: m...@daveyshafik.com 
>>> >  >
>>> >   > [mailto:m...@daveyshafik.com 
>>> >  > ] On Behalf
>>> Of
>>> >   > Davey
>>> >   >   > Shafik
>>> >   >   > Sent: Sunday, April 24, 2016 2:25 AM
>>> >   >   > To: Pierrick Charron >> >   >> >  > >
>>> >   >   > Cc: PHP internals >> > 
>>> >
>>> >   > > internals@lists.php.net> > >;
>>> > paj...@php.net   >> >  >
>>> >   >   > Subject: [PHP-DEV] Re: ext/curl update
>>> >   >   >
>>> >   >   > Hi Pierrick,
>>> >   >   >
>>> >   >   > This should be in master for 7.1, alongside my RFC'ed
>>> patch for
>>> > server
>>> >   > push
>>> >   >   > support.
>>> >   >   >
>>> >   >   > You emailed me directly about the aforementioned patch
>>> so I'll
>>> > just
>>> >   > respond
>>> >   >   > here as it's relevant:
>>> >   >   >
>>> >   >   > The patch should hit in 7.1 but it has been requested
>>> that tests be
>>> >   > added — and
>>> >   >   > we can't add tests with a server push supporting
>>> HTTP/2 server
>>> > against
>>> >   > which to
>>> >   >   > push.
>>> >   >   >
>>> >   >   As from the patch, many constants have nothing to do
>>> with HTTP/2
>>> >   > implementation and add just name/value 

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

[Dmitry Stogov]

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 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
Nullable if Union doesn't pass vote", which, when you think about it, is
not really supporting both.

If Union goes to vote before anything else, voters will to take into
account what they expect to subsequently go to vote. So your stance
relative to that matters. Hence it's not really clear what you want while
you continue to own both.

This is how I understand Dmitry's concerns (correct me if I'm wrong,
Dmitry).

It would be easier to understand if you would *either* abandon Union (for
7.1) and throw your support behind Nullable *or* disown Nullable, let
Dmitry champion it, and the two RFCs to vote as alternatives.

I understand that you see Union as a kind of superset of Nullable (correct
me if I'm wrong) but when it comes to the voting, there's no fair way to
organize that. Someone's going to be unhappy.

Tom


On 4/28/16, 3:16 PM, "Dmitry Stogov"  wrote:

>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" RFC was accepted now, but I
>don't trust in your intention to support it.
>
>
>From: morrison.l...@gmail.com  on behalf of Levi
>Morrison 
>Sent: Thursday, April 28, 2016 10:02:20 PM
>To: Dmitry Stogov
>Cc: Joe Watkins; internals; Tom Worster
>Subject: 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 Nullable Types and Union Types. Some view those
>RFC's as competing, but they can also be orthogonal. I see the value
>in having both.



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

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

[Stanislav Malyshev]

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
would ever use, unlike Eiifel where it is major part of what the
language is. Giving a possibility of implementing it using attributes is
fine. But bringing yet another conceptual framework into PHP looks like
overkill to me.

-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Tom Worster]

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
Nullable if Union doesn't pass vote", which, when you think about it, is
not really supporting both.

If Union goes to vote before anything else, voters will to take into
account what they expect to subsequently go to vote. So your stance
relative to that matters. Hence it's not really clear what you want while
you continue to own both.

This is how I understand Dmitry's concerns (correct me if I'm wrong,
Dmitry).

It would be easier to understand if you would *either* abandon Union (for
7.1) and throw your support behind Nullable *or* disown Nullable, let
Dmitry champion it, and the two RFCs to vote as alternatives.

I understand that you see Union as a kind of superset of Nullable (correct
me if I'm wrong) but when it comes to the voting, there's no fair way to
organize that. Someone's going to be unhappy.

Tom


On 4/28/16, 3:16 PM, "Dmitry Stogov"  wrote:

>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" RFC was accepted now, but I
>don't trust in your intention to support it.
>
>
>From: morrison.l...@gmail.com  on behalf of Levi
>Morrison 
>Sent: Thursday, April 28, 2016 10:02:20 PM
>To: Dmitry Stogov
>Cc: Joe Watkins; internals; Tom Worster
>Subject: 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 Nullable Types and Union Types. Some view those
>RFC's as competing, but they can also be orthogonal. I see the value
>in having both.



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

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

[Björn Larsson]

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 and put
it into vote quickly, maybe having you both as authors or one of
you taking the lead? And again, sorry if I jump into the discussion
uninvited.

/Regards //Björn Larsson/

Den 2016-04-28 kl. 21:16, skrev Dmitry Stogov:

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" RFC was accepted now, but I don't 
trust in your intention to support it.


From: morrison.l...@gmail.com  on behalf of Levi Morrison 

Sent: Thursday, April 28, 2016 10:02:20 PM
To: Dmitry Stogov
Cc: Joe Watkins; internals; Tom Worster
Subject: 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 Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

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

[Rowan Collins]

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
"annotation" in the name, but uses the word "attribute" everywhere in
the actual text.


Yes, I provided many in the initial message, the Wikipedia link [1]
explains it in detail and you may use it as reference for all the other
questions you have here, since it answers all of them.


I meant specifically in the context of C#/.net. You claimed a very 
specific usage within that framework, but all the articles I can find 
refer to them consistently as "attributes" in that context. Event the 
Wikipedia article:


> In the C# programming language, attributes are [...] equivalent to 
annotations in Java.


That's pretty clear to me that the two languages call the same concept 
different things.




The word construct "attribute specification" is completely right, it
specifies which attribute should be applied to the data.


But it completely disagrees with your earlier claim that "The result of 
an annotation is an attribute." There is absolutely no usage of 
"annotation" in that page; there is just a description of syntax for 
applying "attributes".





Method modifiers are a more specialized form of attributes and it makes
sense to refer to them as such because it is less ambiguous than the
word attributes.


It may make sense, but can you point me to any C#/.net documentation 
which describes that relationship? I'm talking about actual usage here, 
not theoretical definitions.




As I said in the initial message, using the term /attribute/ is pretty
much never wrong because the term /attribute/ is so generic. :P


What kind of answer is that? The page clearly describes a Perl feature 
very similar to the feature proposed for PHP, and it very clearly calls 
it "attributes". If it's "never wrong" for Perl, surely it's "never 
wrong" for PHP either?




Actually I checked the dictionaries for the actual definition. This is
also how I documented it in the initial message. All additional language
links were only used to proof that Java is not the only language that
uses the term and that the term is always used in the context.


I have already pointed out that 3 of those links do not back up your 
claim. You appear to dispute this, but I'm increasingly unclear on what 
grounds.


You are perfectly entitled to the opinion that C#, Perl, and Rust are 
*wrong* in their usage of the term, but they absolutely use that term in 
the same way as Hack, not in the way you wish to define it.




That is why there is an empty line between the pages that are actually
documenting the usage of an annotation functionality and the pages that
are using the term annotation correctly in natural language to describe
something. Again, it is about language and terminology.


OK, I'm completely lost now. I thought your argument was that the 
feature should under no circumstances be called "attributes", because 
that is too general a term, and that it should instead be called 
"annotations", because that is the only correct term. Then you link to a 
page which demonstrates *annotations* being used as a general term, and 
*attributes* being used for the feature being proposed.




Me neither, I am saying that the term is too generic and that we should
use the term annotation in order to make it unique, easily
understandable, non-ambiguous in terms of natural language and not in
terms of what others use or do.


Except that the Rust example demonstrates that "annotation" can be used 
just as generically and ambiguously as "attribute". There really is very 
little to choose between the two terms.


Regards,
--
Rowan Collins
[IMSoP]

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

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

[Fleshgrinder]

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 more complicated to implement
thought.

  [assert]
  assert.active= 1
  assert.invariant = 1
  assert.require   = 1 ; preconditions
  assert.ensure= 1 ; postconditions

  class PreconditionError extends AssertionError {}
  class PostconditionError extends AssertionError {}

  function hello(string $who): string {
return "Hello {$who}\n";
  }
  require {
# argument must have content
$who !== '';
# argument cannot contain unprintable characters
ctype_print($who);
  }

  hello('');
  // PHP Warning: require(): argument must have content: "$who !== ''"
  // failed in ...

  hello("\0");
  // PHP Warning: require(): argument cannot contain unprintable
  // characters: "ctype_print($who)" failed in ...

  class A {

private DateTimeImmutable $created;
private DateTimeImmutable $changed;

function f() {}
require {}
// Special scope "old" available...
ensure {
  # error message
  $this->x = old::$x - 42;
}

  }
  ensure {
# created cannot be less than changed time
$this->created <= $this->changed;
  }

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Inline functions

[Dominic Grostate]

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 contributes a large part
it.
On 28 Apr 2016 7:55 p.m., "Nikita Popov"  wrote:

> 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
>> >  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 intensive
>> > repetitive
>> > > tasks.
>> > >
>> > > So how difficult would it be to get the engine to determine if an
>> inline
>> > is
>> > > feasible, then skip the fcall init, and dump the a functions opcode
>> emits
>> > > directly into the current scope?
>> > >
>> > I'm actually working on a proof-of-concept of that already.  I've
>> > already got basic proxy methods getting inlined, and am working up
>> > through expression methods and trying to resolve scoping with $this
>> > and non-publics.
>> >
>> > I'll publish a branch on github when I have something interesting to
>> share.
>> >
>> > -Sara
>> >
>>
>
> I also have a proof-of-concept inlining implementation lying around:
> https://github.com/nikic/php-src/blob/opt/ext/opcache/Optimizer/inlining.c
>
> However it only inlines free functions and static methods, not instance
> methods, because the latter have the $this being null issue. Another
> complication when inlining methods is that we may only know the called
> method if it is either private or final, i.e. there is no possibility of it
> being overwritten in a child class.
>
> One tricky issue with inlining is that we need to unset all the variables
> of the inlined function after the call, otherwise we may cause issues with
> references and destruction order. If these unsets are not eliminated
> through DCE they may be pretty expensive (for a larger number of vars).
> Furthermore inlining increases the number of variables in the function
> (which need to be initialized and destroyed), which may be problematic when
> inlining into unlikely branches. (Register allocation for CVs would improve
> this).
>
> Nikita
>

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

[Bob Weinand]

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
function (array $foo = []) { ... }
to
function (array $foo = null) { if (!$foo) { $foo = []; } ... }

Which satisfies all of todays and future code.

Thanks,
Bob

> Am 28.04.2016 um 20:34 schrieb Dmitry Stogov :
> 
> 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: Anatol Belski; Joe Watkins; internals; Levi Morrison
> Subject: 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 have clear consensus. Or is really anyone 
> disputing this fix?
> 
> Bob Weinand (iPhone)
> 
>> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov :
>> 
>> 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, 2016 8:36:22 PM
>> To: Dmitry Stogov
>> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
>> Subject: 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 that changed and moved the problematic 
>>> code.
>>> 
>>> Anatol, I think we should revert this before 7.0.6 release.
>>> 
>>> Thanks. Dmitry.
>>> 
>>> 
>>> From: morrison.l...@gmail.com  on behalf of Levi 
>>> Morrison 
>>> Sent: Thursday, April 28, 2016 18:40
>>> To: internals
>>> Cc: Dmitry Stogov; Tom Worster
>>> Subject: 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.
>>> 
>>> >> 
>>> interface Foo {
>>>  public function bar(array $baz = null);
>>> }
>>> 
>>> class Hello implements Foo {
>>>  public function bar(array $baz = array())  {}
>>> }
>>> 
>>> ?>
>>> 
>>> 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 important to realize that we
>>> previously *allowed* this behavior since PHP 5.1 but was fixed in
>>> 7.0.6.
>>> 
>>> If instead we had nullable types separately from default values of
>>> null this could change to:
>>> 
>>> >> 
>>> class Hello implements Foo {
>>>  public function bar(array | null $baz = [])  {}
>>> }
>>> 
>>> ?>
>>> 
>>> (or a short-form `?array $baz = []` if short-form passes)
>>> 
>>> This preserves the ability to be null but changes the default value.
>>> Of course, there may be other code changes necessary to future-proof
>>> their code but there current code would now work without having to
>>> rewrite any method bodies (just signatures).
>>> 
>>> In light of this I kindly request that RFCs that add nullable types
>>> for only return values be withdrawn. So that [Union Types][2] and
>>> [Nullable Types][3] can go forward unhindered.
>>> 
>>> 
>>> [1]: https://bugs.php.net/bug.php?id=72119
>>> [2]: https://wiki.php.net/rfc/union_types
>>> [2]: https://wiki.php.net/rfc/nullable_types
>> 
>> Hey Dmitry,
>> 
>> thanks for reverting… but
>> 
>> I've seen you had merged just straight up?
>> I assume this was unintentional (as it should definitely remain fixed in 
>> 7.1).
>> Thus I've reverted your changes in master (only) and added an appropriate 
>> NEWS entry there.
>> 
>> Thanks,
>> Bob
> 


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

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

[Fleshgrinder]

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 the word "attribute" everywhere in
> the actual text.
> 

Yes, I provided many in the initial message, the Wikipedia link [1]
explains it in detail and you may use it as reference for all the other
questions you have here, since it answers all of them. Emphasize mine:

> You can also use *attributes* to control memory placement, code
> generation options or call/return conventions within the function
> being *annotated*.
>
> --- https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

We /annotate/ data and by doing so we add /attributes/.

The C language is a very good example where all attributes are directly
called attributes because there is no other system available to add
attributes. In PHP we have various means to add attributes, so does
Java. *That* is why it is not a good idea to call a specific
functionality /attributes/.

On 4/28/2016 8:02 PM, Rowan Collins wrote:
> According to this page, the syntax which applies an attribute to some
> code is called an "attribute specification":
> https://msdn.microsoft.com/en-us/library/aa664616.aspx
> 

The word construct "attribute specification" is completely right, it
specifies which attribute should be applied to the data. The
functionality at our disposal to do so---addition and specification of
attributes---is through annotating them. Hence, calling the
functionality ...

- Custom Attributes
- Attribute Specifiers
- Custom Attribute Specifiers
- Extended Attributes

... or something in this vain would get my +1. However, all of them are
rather bulky.

On 4/28/2016 8:02 PM, Rowan Collins wrote:
> Again, I've not seen anything saying that .net refers to the "public"
> keyword as an "attribute", or in any way treats it as equivalent to the
> attribute (or, if you insist, annotation) syntax. In fact, the article I
> quoted earlier explicitly distinguishes the two, referring to "public"
> etc as "method-modifiers", and seems clear to me that they are not the
> same thing as attributes:
> https://msdn.microsoft.com/en-us/library/aa664611%28v=vs.71%29.aspx
> 

Method modifiers are a more specialized form of attributes and it makes
sense to refer to them as such because it is less ambiguous than the
word attributes. [1]

BTW: /public/, /protected/, and /private/ are a special form of
modifiers in general and called *access modifiers*:

https://en.wikipedia.org/wiki/Access_modifiers

On 4/28/2016 8:02 PM, Rowan Collins wrote:
>> The name they chose is okay because Perl does not offer any other way of
>> adding attributes to any kind of data in any way (at least none that I
>> am aware off but I am not a Perl programmer). Hence, it is not too
>> dangerous to call this functionality attributes as it would be in our
>> context where many other attributes are already available.
> 
> Surely under your definition scope modifiers like "local"/"global" and
> "my"/"our" would be "attributes"? I think you're really clutching at
> straws to distinguish this case from any of the others, just because it
> doesn't agree with your assumptions.
> 

As I said in the initial message, using the term /attribute/ is pretty
much never wrong because the term /attribute/ is so generic. :P

The only data without any kind of attributes is raw binary data without
any meaning. Note that random data does not count, since randomness
would be an attribute of the data.

> a usually good quality or feature that someone or something has
>
> --- http://www.merriam-webster.com/dictionary/attribute

On 4/28/2016 8:02 PM, Rowan Collins wrote:
> By "confirmation bias", I meant that you'd gone out looking for
> confirmation that people called them "annotations", rather than
> researching what each language calls them.
> 

Actually I checked the dictionaries for the actual definition. This is
also how I documented it in the initial message. All additional language
links were only used to proof that Java is not the only language that
uses the term and that the term is always used in the context.

On 4/28/2016 8:02 PM, Rowan Collins wrote:
> For instance, you linked to a Rust page, which happened to contain the
> word "annotation", but on closer inspection is actually using the terms
> in exactly the opposite way from you: the "lifetime annotation" here is
> a specific syntax to do with lifetimes, and is an "annotation" in the
> loose sense of "you are annotating the source code". Meanwhile, in the
> menu on the left, we can see a section on "Attributes", which look much
> more like arbitrary metadata of the sort we are discussing right now:
> http://rustbyexample.com/attribute.html
> 

That is why there is an empty line between the pages that are actually
documenting the usage of an annotation 

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

[Dmitry Stogov]

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" RFC was accepted now, but I don't 
trust in your intention to support it.


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 10:02:20 PM
To: Dmitry Stogov
Cc: Joe Watkins; internals; Tom Worster
Subject: 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 Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

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

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

[Levi Morrison]

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 Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

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

Re: [PHP-DEV] Inline functions

[Nikita Popov]

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
> >  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 intensive
> > repetitive
> > > tasks.
> > >
> > > So how difficult would it be to get the engine to determine if an
> inline
> > is
> > > feasible, then skip the fcall init, and dump the a functions opcode
> emits
> > > directly into the current scope?
> > >
> > I'm actually working on a proof-of-concept of that already.  I've
> > already got basic proxy methods getting inlined, and am working up
> > through expression methods and trying to resolve scoping with $this
> > and non-publics.
> >
> > I'll publish a branch on github when I have something interesting to
> share.
> >
> > -Sara
> >
>

I also have a proof-of-concept inlining implementation lying around:
https://github.com/nikic/php-src/blob/opt/ext/opcache/Optimizer/inlining.c

However it only inlines free functions and static methods, not instance
methods, because the latter have the $this being null issue. Another
complication when inlining methods is that we may only know the called
method if it is either private or final, i.e. there is no possibility of it
being overwritten in a child class.

One tricky issue with inlining is that we need to unset all the variables
of the inlined function after the call, otherwise we may cause issues with
references and destruction order. If these unsets are not eliminated
through DCE they may be pretty expensive (for a larger number of vars).
Furthermore inlining increases the number of variables in the function
(which need to be initialized and destroyed), which may be problematic when
inlining into unlikely branches. (Register allocation for CVs would improve
this).

Nikita

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

[Dmitry Stogov]

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, 2016 9:47:18 PM
To: Joe Watkins
Cc: Dmitry Stogov; internals; Tom Worster
Subject: 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 separately
> or as part of unions.
>
> So, I'm not understanding why you need to hold up Dmitry any more.
>
> Please, explain.
>
> Cheers
> Joe
>
> On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison  wrote:
>>
>> 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: Thursday, April 28, 2016 8:39:03 PM
>> > To: Dmitry Stogov
>> > Cc: internals; Tom Worster
>> > Subject: 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 versions.
>> >>
>> >> I'm not going to withdraw
>> >> https://wiki.php.net/rfc/nullable_return_types
>> >> It doesn't prohibit usage of nullable for arguments, and even sets
>> >> additional question.
>> >
>> > In that case: are you fine with my RFCs going to vote first (and
>> > soon)? We presently have four somewhat competing RFCs and need to work
>> > out voting order.
>> >
>> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>>
>> It doesn't have an implementation, sure. But you already worked out
>> return types, the basics are already there in parameter types and
>> there's an implementation in HHVM. Do you really think this would be a
>> blocker? There is no reason to believe that a short-hand nullable
>> types implementation cannot be reasonably done.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort
of political campaign. Let me try to straighten this:

As evidenced by this bug report that needs a fix there is a need for
nullable parameter types that is not tied to a default of null.
Dmitry's RFC does not handle this. Nor does Tom's.

There is an RFC that can solve both return types and parameter types.
I'm asking them to withdraw because they don't meet those needs and
there is an RFC that does. It just so happens to be mine. It also
happens to be the first drafted RFC.

This is not an unreasonable request. In fact, it's the much nicer
option that just opening vote on mine first without talking about it
on list at all. And lastly, it's just a request. They don't have to
withdraw.

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

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

[Levi Morrison]

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 separately
> or as part of unions.
>
> So, I'm not understanding why you need to hold up Dmitry any more.
>
> Please, explain.
>
> Cheers
> Joe
>
> On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison  wrote:
>>
>> 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: Thursday, April 28, 2016 8:39:03 PM
>> > To: Dmitry Stogov
>> > Cc: internals; Tom Worster
>> > Subject: 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 versions.
>> >>
>> >> I'm not going to withdraw
>> >> https://wiki.php.net/rfc/nullable_return_types
>> >> It doesn't prohibit usage of nullable for arguments, and even sets
>> >> additional question.
>> >
>> > In that case: are you fine with my RFCs going to vote first (and
>> > soon)? We presently have four somewhat competing RFCs and need to work
>> > out voting order.
>> >
>> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>>
>> It doesn't have an implementation, sure. But you already worked out
>> return types, the basics are already there in parameter types and
>> there's an implementation in HHVM. Do you really think this would be a
>> blocker? There is no reason to believe that a short-hand nullable
>> types implementation cannot be reasonably done.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort
of political campaign. Let me try to straighten this:

As evidenced by this bug report that needs a fix there is a need for
nullable parameter types that is not tied to a default of null.
Dmitry's RFC does not handle this. Nor does Tom's.

There is an RFC that can solve both return types and parameter types.
I'm asking them to withdraw because they don't meet those needs and
there is an RFC that does. It just so happens to be mine. It also
happens to be the first drafted RFC.

This is not an unreasonable request. In fact, it's the much nicer
option that just opening vote on mine first without talking about it
on list at all. And lastly, it's just a request. They don't have to
withdraw.

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

Re: [PHP-DEV] Inline functions

[Dominic Grostate]

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 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 intensive
> repetitive
> > tasks.
> >
> > So how difficult would it be to get the engine to determine if an inline
> is
> > feasible, then skip the fcall init, and dump the a functions opcode emits
> > directly into the current scope?
> >
> I'm actually working on a proof-of-concept of that already.  I've
> already got basic proxy methods getting inlined, and am working up
> through expression methods and trying to resolve scoping with $this
> and non-publics.
>
> I'll publish a branch on github when I have something interesting to share.
>
> -Sara
>

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

[Dmitry Stogov]

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: Anatol Belski; Joe Watkins; internals; Levi Morrison
Subject: 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 have clear consensus. Or is really anyone disputing 
this fix?

Bob Weinand (iPhone)

> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov :
>
> 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, 2016 8:36:22 PM
> To: Dmitry Stogov
> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
> Subject: 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 that changed and moved the problematic 
>> code.
>>
>> Anatol, I think we should revert this before 7.0.6 release.
>>
>> Thanks. Dmitry.
>>
>> 
>> From: morrison.l...@gmail.com  on behalf of Levi 
>> Morrison 
>> Sent: Thursday, April 28, 2016 18:40
>> To: internals
>> Cc: Dmitry Stogov; Tom Worster
>> Subject: 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.
>>
>> >
>> interface Foo {
>>   public function bar(array $baz = null);
>> }
>>
>> class Hello implements Foo {
>>   public function bar(array $baz = array())  {}
>> }
>>
>> ?>
>>
>> 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 important to realize that we
>> previously *allowed* this behavior since PHP 5.1 but was fixed in
>> 7.0.6.
>>
>> If instead we had nullable types separately from default values of
>> null this could change to:
>>
>> >
>> class Hello implements Foo {
>>   public function bar(array | null $baz = [])  {}
>> }
>>
>> ?>
>>
>> (or a short-form `?array $baz = []` if short-form passes)
>>
>> This preserves the ability to be null but changes the default value.
>> Of course, there may be other code changes necessary to future-proof
>> their code but there current code would now work without having to
>> rewrite any method bodies (just signatures).
>>
>> In light of this I kindly request that RFCs that add nullable types
>> for only return values be withdrawn. So that [Union Types][2] and
>> [Nullable Types][3] can go forward unhindered.
>>
>>
>> [1]: https://bugs.php.net/bug.php?id=72119
>> [2]: https://wiki.php.net/rfc/union_types
>> [2]: https://wiki.php.net/rfc/nullable_types
>
> Hey Dmitry,
>
> thanks for reverting… but
>
> I've seen you had merged just straight up?
> I assume this was unintentional (as it should definitely remain fixed in 7.1).
> Thus I've reverted your changes in master (only) and added an appropriate 
> NEWS entry there.
>
> Thanks,
> Bob

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

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

[Bob Weinand]

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 have clear consensus. Or is really anyone disputing 
this fix?

Bob Weinand (iPhone)

> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov :
> 
> 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, 2016 8:36:22 PM
> To: Dmitry Stogov
> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
> Subject: 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 that changed and moved the problematic 
>> code.
>> 
>> Anatol, I think we should revert this before 7.0.6 release.
>> 
>> Thanks. Dmitry.
>> 
>> 
>> From: morrison.l...@gmail.com  on behalf of Levi 
>> Morrison 
>> Sent: Thursday, April 28, 2016 18:40
>> To: internals
>> Cc: Dmitry Stogov; Tom Worster
>> Subject: 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.
>> 
>> > 
>> interface Foo {
>>   public function bar(array $baz = null);
>> }
>> 
>> class Hello implements Foo {
>>   public function bar(array $baz = array())  {}
>> }
>> 
>> ?>
>> 
>> 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 important to realize that we
>> previously *allowed* this behavior since PHP 5.1 but was fixed in
>> 7.0.6.
>> 
>> If instead we had nullable types separately from default values of
>> null this could change to:
>> 
>> > 
>> class Hello implements Foo {
>>   public function bar(array | null $baz = [])  {}
>> }
>> 
>> ?>
>> 
>> (or a short-form `?array $baz = []` if short-form passes)
>> 
>> This preserves the ability to be null but changes the default value.
>> Of course, there may be other code changes necessary to future-proof
>> their code but there current code would now work without having to
>> rewrite any method bodies (just signatures).
>> 
>> In light of this I kindly request that RFCs that add nullable types
>> for only return values be withdrawn. So that [Union Types][2] and
>> [Nullable Types][3] can go forward unhindered.
>> 
>> 
>> [1]: https://bugs.php.net/bug.php?id=72119
>> [2]: https://wiki.php.net/rfc/union_types
>> [2]: https://wiki.php.net/rfc/nullable_types
> 
> Hey Dmitry,
> 
> thanks for reverting… but
> 
> I've seen you had merged just straight up?
> I assume this was unintentional (as it should definitely remain fixed in 7.1).
> Thus I've reverted your changes in master (only) and added an appropriate 
> NEWS entry there.
> 
> Thanks,
> Bob

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

[Rowan Collins]

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 {

 [DataType(DataType.EmailAddress)]
 public string EmailAddress { get; set; }
   }

The `[DataType(DataType.EmailAddress)]` is the annotation and the
attribute that we add to the property is a DataTypeAttribute of DataType
EmailAddress.


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 the word "attribute" everywhere in 
the actual text.


According to this page, the syntax which applies an attribute to some 
code is called an "attribute specification": 
https://msdn.microsoft.com/en-us/library/aa664616.aspx




Here public and EmailAddress are attributes of the instance variable
email and hence properties of a property that together result in a class
or instance attribute.


Again, I've not seen anything saying that .net refers to the "public" 
keyword as an "attribute", or in any way treats it as equivalent to the 
attribute (or, if you insist, annotation) syntax. In fact, the article I 
quoted earlier explicitly distinguishes the two, referring to "public" 
etc as "method-modifiers", and seems clear to me that they are not the 
same thing as attributes: 
https://msdn.microsoft.com/en-us/library/aa664611%28v=vs.71%29.aspx




The name they chose is okay because Perl does not offer any other way of
adding attributes to any kind of data in any way (at least none that I
am aware off but I am not a Perl programmer). Hence, it is not too
dangerous to call this functionality attributes as it would be in our
context where many other attributes are already available.


Surely under your definition scope modifiers like "local"/"global" and 
"my"/"our" would be "attributes"? I think you're really clutching at 
straws to distinguish this case from any of the others, just because it 
doesn't agree with your assumptions.






I haven't looked through any of your other links to see if you've fallen
foul of similar confirmation bias, but am satisfied in my mind that
there are plenty of people outside Hack who call them "attributes".

No confirmation bias


By "confirmation bias", I meant that you'd gone out looking for 
confirmation that people called them "annotations", rather than 
researching what each language calls them.


For instance, you linked to a Rust page, which happened to contain the 
word "annotation", but on closer inspection is actually using the terms 
in exactly the opposite way from you: the "lifetime annotation" here is 
a specific syntax to do with lifetimes, and is an "annotation" in the 
loose sense of "you are annotating the source code". Meanwhile, in the 
menu on the left, we can see a section on "Attributes", which look much 
more like arbitrary metadata of the sort we are discussing right now: 
http://rustbyexample.com/attribute.html



I think a survey of what different languages call their metadata 
features would be interesting, but so far, I'm not seeing a clear bias 
in favour of one or the other.


Like I say, I personally prefer the term "annotations", but I'm not 
going to discount the evidence that major languages like C#/.net, Perl, 
and Rust have chosen the name "attributes" instead.


Regards,
--
Rowan Collins
[IMSoP]

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

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

[Dmitry Stogov]

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, 2016 8:36:22 PM
To: Dmitry Stogov
Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
Subject: 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 that changed and moved the problematic code.
>
> Anatol, I think we should revert this before 7.0.6 release.
>
> Thanks. Dmitry.
>
> 
> From: morrison.l...@gmail.com  on behalf of Levi 
> Morrison 
> Sent: Thursday, April 28, 2016 18:40
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: 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.
>
> 
> interface Foo {
>public function bar(array $baz = null);
> }
>
> class Hello implements Foo {
>public function bar(array $baz = array())  {}
> }
>
> ?>
>
> 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 important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
>
> If instead we had nullable types separately from default values of
> null this could change to:
>
> 
> class Hello implements Foo {
>public function bar(array | null $baz = [])  {}
> }
>
> ?>
>
> (or a short-form `?array $baz = []` if short-form passes)
>
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
>
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
>
>
>  [1]: https://bugs.php.net/bug.php?id=72119
>  [2]: https://wiki.php.net/rfc/union_types
>  [2]: https://wiki.php.net/rfc/nullable_types

Hey Dmitry,

thanks for reverting… but

I've seen you had merged just straight up?
I assume this was unintentional (as it should definitely remain fixed in 7.1).
Thus I've reverted your changes in master (only) and added an appropriate NEWS 
entry there.

Thanks,
Bob

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

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

[Joe Watkins]

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 up Dmitry any more.

Please, explain.

Cheers
Joe

On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison  wrote:

> 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: Thursday, April 28, 2016 8:39:03 PM
> > To: Dmitry Stogov
> > Cc: internals; Tom Worster
> > Subject: 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 versions.
> >>
> >> I'm not going to withdraw
> https://wiki.php.net/rfc/nullable_return_types
> >> It doesn't prohibit usage of nullable for arguments, and even sets
> additional question.
> >
> > In that case: are you fine with my RFCs going to vote first (and
> > soon)? We presently have four somewhat competing RFCs and need to work
> > out voting order.
> >
> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>
> It doesn't have an implementation, sure. But you already worked out
> return types, the basics are already there in parameter types and
> there's an implementation in HHVM. Do you really think this would be a
> blocker? There is no reason to believe that a short-hand nullable
> types implementation cannot be reasonably done.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Dmitry Stogov]

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 8:47:41 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: 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: Thursday, April 28, 2016 8:39:03 PM
> To: Dmitry Stogov
> Cc: internals; Tom Worster
> Subject: 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 versions.
>>
>> I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
>> It doesn't prohibit usage of nullable for arguments, and even sets 
>> additional question.
>
> In that case: are you fine with my RFCs going to vote first (and
> soon)? We presently have four somewhat competing RFCs and need to work
> out voting order.
>
> Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

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

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

[Dmitry Stogov]

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 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 
implementation, and none of us have a good idea how to implement the RFCs.

In addition, nobody can agree which nullable types RFC should go to vote, or 
how the whole nullable type question should be resolved.

Cheers
Joe


On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand 
> wrote:

> 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 that changed and moved the problematic code.
>
> Anatol, I think we should revert this before 7.0.6 release.
>
> Thanks. Dmitry.
>
> 
> From: morrison.l...@gmail.com 
> > on behalf of Levi 
> Morrison >
> Sent: Thursday, April 28, 2016 18:40
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: 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.
>
> 
> interface Foo {
>public function bar(array $baz = null);
> }
>
> class Hello implements Foo {
>public function bar(array $baz = array())  {}
> }
>
> ?>
>
> 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 important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
>
> If instead we had nullable types separately from default values of
> null this could change to:
>
> 
> class Hello implements Foo {
>public function bar(array | null $baz = [])  {}
> }
>
> ?>
>
> (or a short-form `?array $baz = []` if short-form passes)
>
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
>
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
>
>
>  [1]: https://bugs.php.net/bug.php?id=72119
>  [2]: https://wiki.php.net/rfc/union_types
>  [2]: https://wiki.php.net/rfc/nullable_types

Hey Dmitry,

thanks for reverting... but

I've seen you had merged just straight up?
I assume this was unintentional (as it should definitely remain fixed in 7.1).
Thus I've reverted your changes in master (only) and added an appropriate NEWS 
entry there.

Thanks,
Bob

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

[Levi Morrison]

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: Thursday, April 28, 2016 8:39:03 PM
> To: Dmitry Stogov
> Cc: internals; Tom Worster
> Subject: 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 versions.
>>
>> I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
>> It doesn't prohibit usage of nullable for arguments, and even sets 
>> additional question.
>
> In that case: are you fine with my RFCs going to vote first (and
> soon)? We presently have four somewhat competing RFCs and need to work
> out voting order.
>
> Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

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

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

[Bob Weinand]

> 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 allow running 
> the same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.
> 
> 
> Thanks. Dmitry.
> 
> 
> 
> From: Joe Watkins 
> Sent: Thursday, April 28, 2016 8:20:12 PM
> To: Dmitry Stogov
> Cc: Levi Morrison; internals; Tom Worster
> Subject: 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:
> 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 doesn't prohibit usage of nullable for arguments, and even sets additional 
> question.
> 
> Thanks. Dmitry.
> 
> 
> From: morrison.l...@gmail.com 
> > on behalf of Levi 
> Morrison >
> Sent: Thursday, April 28, 2016 6:40:59 PM
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: 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.
> 
>  
> interface Foo {
>public function bar(array $baz = null);
> }
> 
> class Hello implements Foo {
>public function bar(array $baz = array())  {}
> }
> 
> ?>
> 
> 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 important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
> 
> If instead we had nullable types separately from default values of
> null this could change to:
> 
>  
> class Hello implements Foo {
>public function bar(array | null $baz = [])  {}
> }
> 
> ?>
> 
> (or a short-form `?array $baz = []` if short-form passes)
> 
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
> 
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
> 
> 
>  [1]: https://bugs.php.net/bug.php?id=72119
>  [2]: https://wiki.php.net/rfc/union_types
>  [2]: https://wiki.php.net/rfc/nullable_types
> 

Uhm … reading this, it sounds like it was intentional … if yes, then sorry.

But it still allows an easy fix, just pass the value explicitly.
I think we should leave the fix in 7.1 thus.

The bug itself - violating LSP - must be fixed. The only reason why it's fine 
in 7.0 is BC. But it definitely MUST be fixed in 7.1.

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

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

[Dmitry Stogov]

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: 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 versions.
>
> I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
> It doesn't prohibit usage of nullable for arguments, and even sets additional 
> question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

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

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

[Fleshgrinder]

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 blocks are 'annotation' is it's simplest form,
> and we add tags within that annotation to make particular details of
> that annotation both machine readable and humanly prominent. That some
> of these keys may be used to "influences the way the application
> behaves." is secondary?
> 

It is totally secondary but still possible, hence, stating it is
correct. A problem is the that attributes that were added via
annotations are per definition not guaranteed to be executed (influence
the way the application behaves) and are as such not a good fit for
design by contract, validation, nor security checks. However, "per
definition" does not mean that one is not allowed to model it in such a way.

On 4/27/2016 11:36 PM, Lester Caine wrote:
> My continuing irritation is that while subsets keep getting discussed as
> duplicate elements outside of the phpdoc wrapper, there is no provision
> for the annotations that would actually help data validation.
> 

Value objects are a better approach towards validation in the very core
than annotations could ever be.

Validation of user input should happen at the most outer layer to fail
early.

Validation of developers should happen via design by contract where we
currently only have assert() at our disposal.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Joe Watkins]

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 implementation, and none of us have a good idea how to implement the
RFCs.

In addition, nobody can agree which nullable types RFC should go to vote,
or how the whole nullable type question should be resolved.

Cheers
Joe


On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand  wrote:

>
> > 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 that changed and moved the problematic
> code.
> >
> > Anatol, I think we should revert this before 7.0.6 release.
> >
> > Thanks. Dmitry.
> >
> > 
> > From: morrison.l...@gmail.com  on behalf of
> Levi Morrison 
> > Sent: Thursday, April 28, 2016 18:40
> > To: internals
> > Cc: Dmitry Stogov; Tom Worster
> > Subject: 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.
> >
> >  >
> > interface Foo {
> >public function bar(array $baz = null);
> > }
> >
> > class Hello implements Foo {
> >public function bar(array $baz = array())  {}
> > }
> >
> > ?>
> >
> > 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 important to realize that we
> > previously *allowed* this behavior since PHP 5.1 but was fixed in
> > 7.0.6.
> >
> > If instead we had nullable types separately from default values of
> > null this could change to:
> >
> >  >
> > class Hello implements Foo {
> >public function bar(array | null $baz = [])  {}
> > }
> >
> > ?>
> >
> > (or a short-form `?array $baz = []` if short-form passes)
> >
> > This preserves the ability to be null but changes the default value.
> > Of course, there may be other code changes necessary to future-proof
> > their code but there current code would now work without having to
> > rewrite any method bodies (just signatures).
> >
> > In light of this I kindly request that RFCs that add nullable types
> > for only return values be withdrawn. So that [Union Types][2] and
> > [Nullable Types][3] can go forward unhindered.
> >
> >
> >  [1]: https://bugs.php.net/bug.php?id=72119
> >  [2]: https://wiki.php.net/rfc/union_types
> >  [2]: https://wiki.php.net/rfc/nullable_types
>
> Hey Dmitry,
>
> thanks for reverting… but
>
> I've seen you had merged just straight up?
> I assume this was unintentional (as it should definitely remain fixed in
> 7.1).
> Thus I've reverted your changes in master (only) and added an appropriate
> NEWS entry there.
>
> Thanks,
> Bob

Re: [PHP-DEV] Inline functions

[Sara Golemon]

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 intensive repetitive
> tasks.
>
> So how difficult would it be to get the engine to determine if an inline is
> feasible, then skip the fcall init, and dump the a functions opcode emits
> directly into the current scope?
>
I'm actually working on a proof-of-concept of that already.  I've
already got basic proxy methods getting inlined, and am working up
through expression methods and trying to resolve scoping with $this
and non-publics.

I'll publish a branch on github when I have something interesting to share.

-Sara

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

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

[Levi Morrison]

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 versions.
>
> I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
> It doesn't prohibit usage of nullable for arguments, and even sets additional 
> question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

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

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

[Bob Weinand]

> 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 that changed and moved the problematic code.
> 
> Anatol, I think we should revert this before 7.0.6 release.
> 
> Thanks. Dmitry.
> 
> 
> From: morrison.l...@gmail.com  on behalf of Levi 
> Morrison 
> Sent: Thursday, April 28, 2016 18:40
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: 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.
> 
>  
> interface Foo {
>public function bar(array $baz = null);
> }
> 
> class Hello implements Foo {
>public function bar(array $baz = array())  {}
> }
> 
> ?>
> 
> 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 important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
> 
> If instead we had nullable types separately from default values of
> null this could change to:
> 
>  
> class Hello implements Foo {
>public function bar(array | null $baz = [])  {}
> }
> 
> ?>
> 
> (or a short-form `?array $baz = []` if short-form passes)
> 
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
> 
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
> 
> 
>  [1]: https://bugs.php.net/bug.php?id=72119
>  [2]: https://wiki.php.net/rfc/union_types
>  [2]: https://wiki.php.net/rfc/nullable_types

Hey Dmitry,

thanks for reverting… but

I've seen you had merged just straight up?
I assume this was unintentional (as it should definitely remain fixed in 7.1).
Thus I've reverted your changes in master (only) and added an appropriate NEWS 
entry there.

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

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

[Fleshgrinder]

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 your MSDN link [1] because I was pretty sure .net
> referred to them as "attributes", and am amused to find sentences like
> this:
> 
>> The System.ComponentModel.DataAnnotations namespace contains the
> classes that are used as data attributes.
> 
> In other words, the implementer of that particular library preferred the
> word "annotations", but the language/framework itself calls them
> "attributes"; here's a nice summary [2]:
> 
>> For example, the accessibility of a method in a class is specified by
> decorating it with the /method-modifiers/ |public|, |protected|,
> |internal|, and |private|. C# enables programmers to invent new kinds of
> declarative information, called attributes.
> 
> So, that's one rather large ecosystem that calls them "attributes".
> 

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 {

[DataType(DataType.EmailAddress)]
public string EmailAddress { get; set; }
  }

The `[DataType(DataType.EmailAddress)]` is the annotation and the
attribute that we add to the property is a DataTypeAttribute of DataType
EmailAddress.

https://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.datatypeattribute%28v=vs.95%29.aspx

Note that you could achieve the above in PHP with the property type RFC:

   class Customer {

  public EmailAddress $email;

   }

Here public and EmailAddress are attributes of the instance variable
email and hence properties of a property that together result in a class
or instance attribute.

On 4/28/2016 11:36 AM, Rowan Collins wrote:
> Your claims for Perl also don't make much sense:
> 
>> Last but not least, Perl has/attribute/  support. However, Perl actually
>> uses it for interaction with*all*  attributes that can be set. Hence,
>> this is what attributes really do.
>>
>> http://perldoc.perl.org/attributes.html
> 
> None of the built-in attributes mentioned in that manual are standard
> syntax used in the majority of Perl programs; in fact, they are all
> marked as experimental, and most of the examples are of defining custom
> attributes. As far as I can see, this is Perl's version of precisely the
> feature that is being proposed for PHP.
> 

The name they chose is okay because Perl does not offer any other way of
adding attributes to any kind of data in any way (at least none that I
am aware off but I am not a Perl programmer). Hence, it is not too
dangerous to call this functionality attributes as it would be in our
context where many other attributes are already available.

The fact that it is experimental does not add anything to this discussion.

On 4/28/2016 11:36 AM, Rowan Collins wrote:
> I haven't looked through any of your other links to see if you've fallen
> foul of similar confirmation bias, but am satisfied in my mind that
> there are plenty of people outside Hack who call them "attributes".
> 
> 
> [1] https://msdn.microsoft.com/en-us/library/dd901590%28VS.95%29.aspx
> [2] https://msdn.microsoft.com/en-us/library/aa664611%28v=vs.71%29.aspx
> 
> Regards,

No confirmation bias and as I said, Microsoft got it completely right.
To give you an analogy, Microsoft is calling the egg an egg and the
chicken a chicken. We would be calling a chicken an egg because it is
able to create eggs.

In other words: an *annotation* allows you to add additional custom
*attributes* to data that cannot be added by other means.

:)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[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 allow running the 
same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.


Thanks. Dmitry.



From: Joe Watkins 
Sent: Thursday, April 28, 2016 8:20:12 PM
To: Dmitry Stogov
Cc: Levi Morrison; internals; Tom Worster
Subject: 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:
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 doesn't prohibit usage of nullable for arguments, and even sets additional 
question.

Thanks. Dmitry.


From: morrison.l...@gmail.com 
> on behalf of Levi 
Morrison >
Sent: Thursday, April 28, 2016 6:40:59 PM
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: 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 important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

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

[Joe Watkins]

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:

> 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 doesn't prohibit usage of nullable for arguments, and even sets
> additional question.
>
> Thanks. Dmitry.
>
> 
> From: morrison.l...@gmail.com  on behalf of Levi
> Morrison 
> Sent: Thursday, April 28, 2016 6:40:59 PM
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: 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.
>
> 
> interface Foo {
> public function bar(array $baz = null);
> }
>
> class Hello implements Foo {
> public function bar(array $baz = array())  {}
> }
>
> ?>
>
> 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 important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
>
> If instead we had nullable types separately from default values of
> null this could change to:
>
> 
> class Hello implements Foo {
> public function bar(array | null $baz = [])  {}
> }
>
> ?>
>
> (or a short-form `?array $baz = []` if short-form passes)
>
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
>
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
>
>
>   [1]: https://bugs.php.net/bug.php?id=72119
>   [2]: https://wiki.php.net/rfc/union_types
>   [2]: https://wiki.php.net/rfc/nullable_types
>

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

[Dmitry Stogov]

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 doesn't prohibit usage of nullable for arguments, and even sets additional 
question.

Thanks. Dmitry.


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 6:40:59 PM
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: 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 important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

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

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

[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 that changed and moved the problematic code.

Anatol, I think we should revert this before 7.0.6 release.

Thanks. Dmitry.


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 18:40
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: 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 important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

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

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

[Rowan Collins]

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 verbose. It would be amazing to have 
something like Perl6's "Junctions": 
https://perlgeek.de/blog-en.cgi/perl-5-to-6/08-junctions.html


$foo instanceof any(Foo, Bar)

Well, I can dream... ;)


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

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

[Levi Morrison]

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 important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

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

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

[Bob Weinand]

> 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, 2016 at 5:00 AM, Josh Di Fabio 
> wrote:
> 
>> 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 our built-in types include
>>> `ArrayAccess & Traversable & Countable` and `Countable & Iterator`.
>>> 
>>> Some people have suggest I merge this and union types into one RFC.
>>> For now I'll just proceed with them separately to gain feedback.
>>> 
>>>  [1]: http://wiki.php.net/rfc/intersection_types
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>> 
>> 
>> To me, it seems that intersection types are more useful than union
>> types (other than the obvious null|Foo and array|Traversable cases) as
>> they'd allow us to write smaller interfaces and better follow ISP in
>> userland, with interfaces becoming much more convenient for
>> documenting the requirements of a parameter.
>> 
>> At present we tend to have incomplete implementations of interfaces
>> (e.g. throw OperationNotSupportedException). Union types would allow
>> us to create more, smaller interfaces and avoid situations where the
>> type of a parameter doesn't accurately reflect the method's true
>> requirements, or where concretions are incomplete implementations of
>> an interface.
>> 
>> Thanks for your efforts, Levi, I'm excited about this one!
> 
> -- 
> Guilherme Blanco
> Lead Architect at E-Block

Who’s top-posting here? ;-)

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.
Also, instanceof would not (at least not currently) work with scalar types, 
array or callable. (i.e. $foo instanceof string doesn’t work). And thus $foo 
instanceof Foo & callable doesn’t either. Which is quite a difference to 
intersection/union types.

Bob

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

[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, 2016 at 5:00 AM, Josh Di Fabio 
wrote:

> 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 our built-in types include
> > `ArrayAccess & Traversable & Countable` and `Countable & Iterator`.
> >
> > Some people have suggest I merge this and union types into one RFC.
> > For now I'll just proceed with them separately to gain feedback.
> >
> >   [1]: http://wiki.php.net/rfc/intersection_types
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> To me, it seems that intersection types are more useful than union
> types (other than the obvious null|Foo and array|Traversable cases) as
> they'd allow us to write smaller interfaces and better follow ISP in
> userland, with interfaces becoming much more convenient for
> documenting the requirements of a parameter.
>
> At present we tend to have incomplete implementations of interfaces
> (e.g. throw OperationNotSupportedException). Union types would allow
> us to create more, smaller interfaces and avoid situations where the
> type of a parameter doesn't accurately reflect the method's true
> requirements, or where concretions are incomplete implementations of
> an interface.
>
> Thanks for your efforts, Levi, I'm excited about this one!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

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

[lp_benchmark_robot]

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
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.10% -0.70%  0.23%  
  7.21%
:-|   Drupal 7.36 cgi -T1  0.22% -0.63% -0.15%  
  4.64%
:-(   MediaWiki 1.23.9 cgi -T5000  0.07% -1.44%  0.06%  
  3.88%
:-)   bench.php cgi -T100  0.14%  1.53% 25.25%  
  0.62%
:-)  micro_bench.php cgi -T10  0.01%  2.21%  4.76%  
  2.80%
:-)  mandelbrot.php cgi -T100  0.01%  5.40% 33.79%  
 -2.64%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/ugly-benchmark-results-for-php-master-2016-04-28/

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] PHP Attributes -> docBloc alternatives ...

[Rowan Collins]

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 preferred practices in the PHP code ... which is
one reason I see that some of the developments have been thankfully
suspended.



As far as I know, the PHP core has never dictated docblock contents, or 
any other aspect of coding style. Such decisions are up to "the 
community", which is a very broad concept. PHP-FIG is an attempt to get 
that community "around a table" to decide on a common style, and common 
ways of working.


If you want to follow a different style, you can; if you want to form an 
alternative community group to spread that style, you can. None of that 
has anything to do with the core language.




Is composer now the only supported installation tool?


Supported by whom? It's certainly not supported by the core language, 
it's just a program you can use. However, it seems to meet people's 
needs better than previous alternatives, so it is very popular.


Regards,
Rowan Collins
[IMSoP]

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

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

[Josh Di Fabio]

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 our built-in types include
> `ArrayAccess & Traversable & Countable` and `Countable & Iterator`.
>
> Some people have suggest I merge this and union types into one RFC.
> For now I'll just proceed with them separately to gain feedback.
>
>   [1]: http://wiki.php.net/rfc/intersection_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

To me, it seems that intersection types are more useful than union
types (other than the obvious null|Foo and array|Traversable cases) as
they'd allow us to write smaller interfaces and better follow ISP in
userland, with interfaces becoming much more convenient for
documenting the requirements of a parameter.

At present we tend to have incomplete implementations of interfaces
(e.g. throw OperationNotSupportedException). Union types would allow
us to create more, smaller interfaces and avoid situations where the
type of a parameter doesn't accurately reflect the method's true
requirements, or where concretions are incomplete implementations of
an interface.

Thanks for your efforts, Levi, I'm excited about this one!

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

[PHP-DEV] Inline functions

[Dominic Grostate]

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 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 intensive repetitive
tasks.

So how difficult would it be to get the engine to determine if an inline is
feasible, then skip the fcall init, and dump the a functions opcode emits
directly into the current scope?

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

[Lester Caine]

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 ... which is
one reason I see that some of the developments have been thankfully
suspended. The changes to phpdocumentor are also at odds with core
practices and that is why I am putting my hand up here. This needs to be
agreed in the core first and personally I'd prefer that this annotation
practice was the primary one, and adding hard coded options remained
optional not enabled by default.

Is composer now the only supported installation tool? Even phpdocumentor
installer advises using other methods because of the mess composer
creates if you are installing more than one 'application', but the only
supported method for using php-annotations is via composer ... creating
it's own problems when trying to add back code that existed in the past.

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