Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

guilhermebla...@gmail.com wrote on 26/11/2015 01:13:

Ok, so I'll explain why it's not "the same way" as you imagine.

I've heard this many times already so I'll save you keystrokes.
- "Sure, we can do that on docblocks"
- "Based on that, it doesn't need to be part of core and can safely be 
implemented as a PECL extension"




OK, as far as everything I was talking about, this is all rather a straw 
man, but perhaps that's just a miscommunication on my part, so let me 
clear that up:


I have never suggested, and would not support a suggestion, that this be 
implemented as an extension. I can absolutely see the advantage to 
having a first-class syntax, baked into the main parser.


With that out of the way, we are back to the main point I was trying to 
make which is that that syntax could, if we wanted, live inside the 
context of /** */ blocks, which are already treated differently from 
comments. The parsing problems within that context are very similar to 
the parsing problems in any other context (again, assuming that this is 
being implemented directly in the core parser, not in any kind of 
extension).


So, the pros and cons of that are not to do with the parsing but to do with:
- potential compatibility with existing code, which may be tricky as 
there is no standard to base the feature on
- the ability to polyfill code in older PHP versions, which is useful 
but not something we have aimed for with previous features
- on the other side, the perception that docblocks are "just comments", 
which would be hard to dispel even if we renamed them "metadata blocks"


Anyway, I apologise for drawing out this part of the discussion for so 
long. I actually think it's just one of many decisions that needs making 
before this feature can be attempted, probably starting with just what 
an annotation consists of - is it a label with some text attached? a 
resolved class name with parsed PHP code passed to its constructor (some 
people have mentioned arrays and heredocs as parameters to annotations)? 
somewhere between the two?


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

Hi, Rowan. I'll respond to some points that have become recurrent.

1) It's might not be objectively bad to add this feature in docblocks, but
it will be objectively wrong to keep calling them "DocBlocks" if they are
no longer documentation-only blocks.

2) Even though PHP already treats docblocks differently from comments,
that's not the common view on userland, nor is explained on the manuals.
There are no separate entries to explain docblocks, and no mention to them
on the "Comments" page. The Reflection method to retrieve DocBlocks is
"getDocCOMMENT", which suggests they are comment that do not affect runtime
behaviour.

We'd have to update the comments page to say "'/*' starts a comment, unless
if they're immediately followed by another asterisk ('/**'), in which case
it may or may not be a comment, depends on the following token". It's very
confusing.

3) To make this work within docblocks, we'd have to get rid of at least one
configuration setting (opcode.save_comments).

4) You've suggested disregarding docblock stripping from transpilers and
obfuscators, because they are not first-class citizens, even though those
are part of the PHP ecosystem and affect users.

5) We'd have a harder time making decisions on syntax for docblocks,
because there are already multiple different implementations, and because
people will have a hard time agreeing on some points, like the one
guilherme made about the asterisks (*) or spaces being part of multiline
annotation or not.

Whereas none of these points are issues for a native syntax outside
docblocks, because it'd be a completely different feature that would reside
in new syntax, not in modification of current syntax.

2015-11-26 8:06 GMT-02:00 Rowan Collins :

> guilhermebla...@gmail.com wrote on 26/11/2015 01:13:
>
>> Ok, so I'll explain why it's not "the same way" as you imagine.
>>
>> I've heard this many times already so I'll save you keystrokes.
>> - "Sure, we can do that on docblocks"
>> - "Based on that, it doesn't need to be part of core and can safely be
>> implemented as a PECL extension"
>>
>>
> OK, as far as everything I was talking about, this is all rather a straw
> man, but perhaps that's just a miscommunication on my part, so let me clear
> that up:
>
> I have never suggested, and would not support a suggestion, that this be
> implemented as an extension. I can absolutely see the advantage to having a
> first-class syntax, baked into the main parser.
>
> With that out of the way, we are back to the main point I was trying to
> make which is that that syntax could, if we wanted, live inside the context
> of /** */ blocks, which are already treated differently from comments. The
> parsing problems within that context are very similar to the parsing
> problems in any other context (again, assuming that this is being
> implemented directly in the core parser, not in any kind of extension).
>
> So, the pros and cons of that are not to do with the parsing but to do
> with:
> - potential compatibility with existing code, which may be tricky as there
> is no standard to base the feature on
> - the ability to polyfill code in older PHP versions, which is useful but
> not something we have aimed for with previous features
> - on the other side, the perception that docblocks are "just comments",
> which would be hard to dispel even if we renamed them "metadata blocks"
>
> Anyway, I apologise for drawing out this part of the discussion for so
> long. I actually think it's just one of many decisions that needs making
> before this feature can be attempted, probably starting with just what an
> annotation consists of - is it a label with some text attached? a resolved
> class name with parsed PHP code passed to its constructor (some people have
> mentioned arrays and heredocs as parameters to annotations)? somewhere
> between the two?
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Benchmark Results for PHP Master 2015-11-26

[lp_benchmark_robot]

Results for project PHP master, build date 2015-11-26 09:26:27+02:00
commit: f9dd83cbe37bcbae173fb3e08b62cfc1c2718085
revision date:  2015-11-26 12:00:37+08: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.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+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.20%  0.67%  2.69%  
  7.04%
:-)   Drupal 7.36 cgi -T1  0.80%  1.58%  1.48%  
  3.50%
:-)   MediaWiki 1.23.9 cgi -T5000  0.58%  0.39%  1.97%  
  3.53%
:-( bench.php cgi -T1  0.40% -3.28% -1.98%  
  9.78%
:-(   micro_bench.php cgi -T1  0.03% -1.25%  0.62%  
  5.75%
:-)mandelbrot.php cgi -T1  0.16%  1.69%  1.23%  
  5.30%
---
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.
* Relative Standard Deviation (Standard Deviation/Average)

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

[PHP-DEV] PHP 7.0.0RC8 is available

[ab]

Hi,

The eighth release candidate for 7.0.0 was just released and can be
downloaded from:

https://downloads.php.net/~ab/

The Windows binaries are available at

http://windows.php.net/qa/

This release contains fixes for yet 11 reported bugs. Given no major issue
were discovered in between, PHP 7.0.0 RC 8 certainly prepares the short jump
to the RTM on December 3rd.

Please test it carefully, and report any bugs in the bug system.


Below is the verification information for the downloads:

php-7.0.0RC8.tar.bz2
SHA256 hash:
8c46621e80b610749d2d31439e9b6db7b881c0249d1df1f4c3e05fdd46a2d108
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWVTPPAAoJELyqMOqcDVdjQMUH/iPZUj4XUlirrvQLvp3lCkye
zaHKlz7ear4OnrTkhdNgzQ5DeIFxQu3bRkggnkOC29Ht8H7fmxrSr35xGU5+UqZL
zpEI6y/wFSJKPhOBPg/EBNsYbreuJ821f172bYvmnUX34Lecm7yOaVGdrORKdzm1
A5UQoKJf6Fvl8XtPhtFc+unkMacDxmcxSQMqES+SQLM+U3IJE5Ejj0qPGjuDw6SI
nf1cgv5x+Dm0IsaQKx732iHrmrCIi0cU6PD21CpIIpKrcylBaRNNnvNDWeZH26JV
qxIpg4Tz+6wDbGGZLwGChlnwOt2hlw7yv7u2V6VTaSX+Pbby+k9v2Gf2zKqopHg=
=fy6J
-END PGP SIGNATURE-


php-7.0.0RC8.tar.gz
SHA256 hash:
cbf6e79e855b4290dd38c6bdc17ed58fc84b308e4a36f907830ca0b387da2f9b
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWVTPSAAoJELyqMOqcDVdjmUcIAK062vrtRCau/vnL417IlDo+
W5cIA2AaupF7v0ZKOTnlz7xGUlpdt7vUIiDSzkWl/dfeeSHRMQ1Zs9AD47/PfwsL
hpoQRaIdsCH7bRhxgVUcXjpBSNYtFoaCotAP8FV/hLYHI8qlxdj8HIlSpJOTLRgr
6IJH9hFHgouiHwdZ8LvPR0nQ2XyXWz2/bjkx4/I2k0RFeLBeom7cgw1hwb5JWQCQ
Q1KRax0fGTmJPI5Vbhxvyd00rEpt//4qAyPc/2kPl72n6U/2253Sq9LFyYEScMEf
R+roVn19Mu0ww6Aa8/6k5r/cHhmlNAbtYPr3oNduZirN5TmqxAFvIjxEvY5N6M4=
=WZk7
-END PGP SIGNATURE-


php-7.0.0RC8.tar.xz
SHA256 hash:
24876ab6dcb810b7bc423ef21abafc73ad12841dd1288c5a592c0621612a1801
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWVTPVAAoJELyqMOqcDVdjXFAIAMdeWUXE9yLRpgpubH97HpGQ
+zc1DPYFEaSQ7y1XOel3KJBdVA/I2wgAr1+GtwsrsUf7NCtW66r6UejuuHes0xiY
BH9CTf3wrEOXQFyJrU46XDQ+AOUi6YmTXZZzzmCxV8rVIa0UctHcOIJR0RY3PbeI
UrXVpbASssXDZ157hBCtNSYRA7IxZoGtk6QYiVTbqO6lT+mdjRrXoBawAFBFbXnM
gu9Qih50KMHsVXnJ9RWhOnGXoR5lH/OQiv69zi4K0Sm0S9O335yCBZox1D4HyTTS
UMbYqkLTSEiGUsWS2vZ1BFNRJp5vgiessjsD9wmRmHPz0EEOMDiZLKTGdVB/g84=
=Ix8r
-END PGP SIGNATURE-


Regards,
Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs


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

Re: [PHP-DEV] Native Annotation Syntax

[Levi Morrison]

> Ah, and please stop saying "it should be in docblock". This argument is
> just bull... to suppress the actual people interested to see this natively
> available and just exposes your lack of interest into language improvement.

Every feature has a cost and benefit. It is perfectly fine to have the
opinion that a feature is better left out of the language based on
that cost. Being against a feature does not mean that person is
against language improvement or has a lack of interest.

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

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

Hi Pedro,

I agree with most of the points in your last mail. At the end of the 
day, the reasons are fairly subjective, and relate to how the feature 
will be perceived, and the freedom to design it without annoying people, 
but that doesn't stop them being real.


However I would like to come back on this one:

Pedro Cordeiro wrote on 26/11/2015 11:46:
4) You've suggested disregarding docblock stripping from transpilers 
and obfuscators, because they are not first-class citizens, even 
though those are part of the PHP ecosystem and affect users.


You're putting words into my mouth there; I never said to disregard the 
tools themselves, I disputed that they will be disadvantaged by one 
syntax over another.


Transpilers and obfuscators will have to make changes either way, if 
they are to support annotations; the nature of those changes is 
different inside and outside docblocks, but that doesn't seem that big a 
deal to me. Whatever the syntax, they will have to do two things: 1) 
parse the source code for annotations, adding them to whatever AST or 
similar they use; 2) output those annotations (with any relevant 
transforms) in the appropriate syntax. I don't see /** @Foo(42) */ as 
fundamentally harder to do that with than << Foo(42) >>, or whatever 
other syntax anyone comes up with.


Other than this point, this e-mail is a much better summary of why 
docblocks should not be used than any details about which of two 
syntaxes (that we haven't invented yet) parsers might or might not find 
harder.


As I say, apologies for side-tracking the conversation for so long, I 
was intending it to be one decision among many, and wanted to make sure 
we'd captured a good reason for the decision, so that it could be 
justified in future.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Let's be clear. I haven't seen any user asking for traits, which introduced
almost the same amount of performance cost and complexity to ZE. It was
proposed by a "long term contributor" and everybody said yay.

When multiple userland people ask about the same feature, every single
major framework uses a hackish way to suppress a language deficiency, and
internals developers don't move a finger (or even care to reply here) about
the subject, it clearly exposes to me they're not paying attention to
user's needs. This is lack of interest, but you can choose better words.

Regards,

On Thu, Nov 26, 2015 at 9:51 AM, Levi Morrison  wrote:

> > Ah, and please stop saying "it should be in docblock". This argument is
> > just bull... to suppress the actual people interested to see this
> natively
> > available and just exposes your lack of interest into language
> improvement.
>
> Every feature has a cost and benefit. It is perfectly fine to have the
> opinion that a feature is better left out of the language based on
> that cost. Being against a feature does not mean that person is
> against language improvement or has a lack of interest.
>



-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

guilhermebla...@gmail.com wrote on 26/11/2015 15:14:

I haven't seen any user asking for traits


Just because you didn't see it, doesn't mean it didn't happen.

I just did a very quick search on Google for php + mixins, limited to 
2007 or earlier (long before the current Trait implementation was born), 
and got plenty of results lamenting the lack of support for horizontal 
reuse in PHP.


See for yourself: 
https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins


It's a common accusation of projects like this that time was spent on X 
that should have been spent on Y, but that's nearly always a massive 
over-simplification.


Let's not spend too much time worrying if specific people are interested 
- they may just be on holiday, or busy elsewhere, or just not have much 
to say until someone assembles a few more details about the proposed 
feature. Keep it constructive, lay out how you think the feature should 
look and why, what questions are still open, and see what's needed to 
move it forward.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

Hey, Rowan, don't apologize for making the case for what you believed to be
the right way. I'm glad I could summarize my views in a way that you could
agree with me.

I've reread your point about the transpilers and obfuscators, and you're
right, I misunderstood what you said. I'm sorry.

Now, I'd be willing to create a new RFC draft for a native annotation
syntax, targeted at 7.1, this time explaining the reasons NOT to do this in
docblocks nor in a seperate extension, so the discussion won't get
sidetracked again. I'd need some help with the patches, though, since I
don't have any experience with the internals.

There is still the issue of complexity added to the engine, which we could
discuss. I'd like to hear more from a long-term contributor about that, if
it's possible. Were there any performance implications on the previously
submitted patch?

Thank you everyone for the great discussion.

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Ok then. I'll pretend that lack of interest didn't happen many other
situations (like http://marc.info/?t=14460876781) and move on.

I don't want to bring the patch up to date/simplify it without a clear
decision of at least be willing to discuss the patch and not reject by all
means.
I'd propose a voting as "Are you ready for Annotations yet?". Every core
developer understands (and can base their decisions) by looking at the
complexity of the old patch.

Once voting completes and IF it gets approved, I'll gladly put it up to
date for consideration and update the RFC.

[]s,

On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins 
wrote:

> guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
>
>> I haven't seen any user asking for traits
>>
>
> Just because you didn't see it, doesn't mean it didn't happen.
>
> I just did a very quick search on Google for php + mixins, limited to 2007
> or earlier (long before the current Trait implementation was born), and got
> plenty of results lamenting the lack of support for horizontal reuse in PHP.
>
> See for yourself:
> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins
>
> It's a common accusation of projects like this that time was spent on X
> that should have been spent on Y, but that's nearly always a massive
> over-simplification.
>
> Let's not spend too much time worrying if specific people are interested -
> they may just be on holiday, or busy elsewhere, or just not have much to
> say until someone assembles a few more details about the proposed feature.
> Keep it constructive, lay out how you think the feature should look and
> why, what questions are still open, and see what's needed to move it
> forward.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] Native Annotation Syntax

[Chris Riley]

On 26 November 2015 at 16:05, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Ok then. I'll pretend that lack of interest didn't happen many other
> situations (like http://marc.info/?t=14460876781) and move on.
>
> I don't want to bring the patch up to date/simplify it without a clear
> decision of at least be willing to discuss the patch and not reject by all
> means.
> I'd propose a voting as "Are you ready for Annotations yet?". Every core
> developer understands (and can base their decisions) by looking at the
> complexity of the old patch.
>
> Once voting completes and IF it gets approved, I'll gladly put it up to
> date for consideration and update the RFC.
>
> []s,
>
> On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins 
> wrote:
>
> > guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
> >
> >> I haven't seen any user asking for traits
> >>
> >
> > Just because you didn't see it, doesn't mean it didn't happen.
> >
> > I just did a very quick search on Google for php + mixins, limited to
> 2007
> > or earlier (long before the current Trait implementation was born), and
> got
> > plenty of results lamenting the lack of support for horizontal reuse in
> PHP.
> >
> > See for yourself:
> >
> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins
> >
> > It's a common accusation of projects like this that time was spent on X
> > that should have been spent on Y, but that's nearly always a massive
> > over-simplification.
> >
> > Let's not spend too much time worrying if specific people are interested
> -
> > they may just be on holiday, or busy elsewhere, or just not have much to
> > say until someone assembles a few more details about the proposed
> feature.
> > Keep it constructive, lay out how you think the feature should look and
> > why, what questions are still open, and see what's needed to move it
> > forward.
> >
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

Given that a lot of userland people have voting rights; I would suspect
that an annotations rfc would pass, provided it met the needs of these
users. As far as docblocks vs native goes - you've convinced me that native
would be best, previously I'd have been more in favour of adding a
getAnnotations method to ReflectionClass/Method/Property, to pull in
annotations from docblocks.

I'd like to see this goto a new RFC here are some questions though:

- Can annotations be applied to functions?
- Class constants?
- Should annotations be a special type eg annotation Foo{} or just a class?
- Do we want to add decorator support at the same time? (
http://thecodeship.com/patterns/guide-to-python-function-decorators/)

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
Ok then. I'll pretend that lack of interest didn't happen many other 
situations (like http://marc.info/?t=14460876781) and move on.


It's possible that a lot of the core devs are still concentrating on 
getting the changes in 7.0 bedded in, and have more time to discuss 
features for 7.1 in a month or two.


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

Re: [PHP-DEV] Native Annotation Syntax

[Levi Morrison]

On Thu, Nov 26, 2015 at 9:57 AM, Rowan Collins  wrote:
> guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
>>
>> Ok then. I'll pretend that lack of interest didn't happen many other
>> situations (like http://marc.info/?t=14460876781) and move on.
>
>
> It's possible that a lot of the core devs are still concentrating on getting
> the changes in 7.0 bedded in, and have more time to discuss features for 7.1
> in a month or two.

At least a few are working on features of their own.

I am curious – a quick scan of this thread didn't seem to actually
propose anything new. It's just discussion about same RFC that was
already rejected. Correct?

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

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

Levi, I was asking about the reasons it was rejected. While researching, I
found the original RFC was voted with 123 votes (71% approval), and yet was
marked as 'declined'. I didn't know why, couldn't find why, so I figured
I'd ask (as it strikes me as a major feature that's missing).

2015-11-26 15:11 GMT-02:00 Levi Morrison :

> On Thu, Nov 26, 2015 at 9:57 AM, Rowan Collins 
> wrote:
> > guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
> >>
> >> Ok then. I'll pretend that lack of interest didn't happen many other
> >> situations (like http://marc.info/?t=14460876781) and move on.
> >
> >
> > It's possible that a lot of the core devs are still concentrating on
> getting
> > the changes in 7.0 bedded in, and have more time to discuss features for
> 7.1
> > in a month or two.
>
> At least a few are working on features of their own.
>
> I am curious – a quick scan of this thread didn't seem to actually
> propose anything new. It's just discussion about same RFC that was
> already rejected. Correct?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Native Annotation Syntax

[guilhermebla...@gmail.com]

Answers inline

On Thu, Nov 26, 2015 at 11:58 AM, Chris Riley  wrote:

>
> On 26 November 2015 at 16:05, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Ok then. I'll pretend that lack of interest didn't happen many other
>> situations (like http://marc.info/?t=14460876781) and move on.
>>
>> I don't want to bring the patch up to date/simplify it without a clear
>> decision of at least be willing to discuss the patch and not reject by all
>> means.
>> I'd propose a voting as "Are you ready for Annotations yet?". Every core
>> developer understands (and can base their decisions) by looking at the
>> complexity of the old patch.
>>
>> Once voting completes and IF it gets approved, I'll gladly put it up to
>> date for consideration and update the RFC.
>>
>> []s,
>>
>> On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins 
>> wrote:
>>
>> > guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
>> >
>> >> I haven't seen any user asking for traits
>> >>
>> >
>> > Just because you didn't see it, doesn't mean it didn't happen.
>> >
>> > I just did a very quick search on Google for php + mixins, limited to
>> 2007
>> > or earlier (long before the current Trait implementation was born), and
>> got
>> > plenty of results lamenting the lack of support for horizontal reuse in
>> PHP.
>> >
>> > See for yourself:
>> >
>> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins
>> >
>> > It's a common accusation of projects like this that time was spent on X
>> > that should have been spent on Y, but that's nearly always a massive
>> > over-simplification.
>> >
>> > Let's not spend too much time worrying if specific people are
>> interested -
>> > they may just be on holiday, or busy elsewhere, or just not have much to
>> > say until someone assembles a few more details about the proposed
>> feature.
>> > Keep it constructive, lay out how you think the feature should look and
>> > why, what questions are still open, and see what's needed to move it
>> > forward.
>> >
>> >
>> > Regards,
>> > --
>> > Rowan Collins
>> > [IMSoP]
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>>
>> --
>> Guilherme Blanco
>> MSN: guilhermebla...@hotmail.com
>> GTalk: guilhermeblanco
>> Toronto - ON/Canada
>>
>
> Given that a lot of userland people have voting rights; I would suspect
> that an annotations rfc would pass, provided it met the needs of these
> users. As far as docblocks vs native goes - you've convinced me that native
> would be best, previously I'd have been more in favour of adding a
> getAnnotations method to ReflectionClass/Method/Property, to pull in
> annotations from docblocks.
>
> I'd like to see this goto a new RFC here are some questions though:
>
> - Can annotations be applied to functions?
>

Yes, classes, interfaces, traits, methods, properties, functions.
Unfortunately we can't apply to namespaces as they don't exist after
compile time.


> - Class constants?
>

No, there's no Reflection data structure around them and imposing one would
be a serious BC break


> - Should annotations be a special type eg annotation Foo{} or just a class?
>

Annotation classes would be annotated with @Annotation and their
corresponding @Target (where they could be applied).


> - Do we want to add decorator support at the same time? (
> http://thecodeship.com/patterns/guide-to-python-function-decorators/)
>

No. Annotations by itself is already a big endeavor and including more
stuff would only make it harder to implement/digest/approve.
What if Annotation gets approved, but people want decorator out? More
work...
Nothing prevent us to make a subsequent RFC to support decorators if the
first one gets accepted.


Regards,

-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

[PHP-DEV] HashDos protection

[Nikita Popov]

Hi internals!

This mail turned out to be rather long, so I'll start with a TL;DR:

To fix the HashDos vulnerability for *all* cases (rather than just GET/POST
parsing), I propose to introduce collision counting during hashtable
insertion operations. This will throw a fatal error if the number of
collisions during an insertion operation exceed a certain threshold.

Implementation: https://github.com/php/php-src/pull/1565

>From my testing the change has no negative performance impact. The change
is small and does not break ABI.

Tracking bug (with various implementations):
https://bugs.php.net/bug.php?id=70644

What are your thoughts on this?

Nikita

-

For those not familiar with HashDos or interested in some considerations
regarding alternative implementations, the original mail:

In PHP 5.3.9 a partial fix for the HashDos vulnerability was introduced in
the form of max_input_vars. As a recap, HashDos exploits the fact that
hashtables (which PHP uses ubiquitously) perform very badly if the hashes
of many elements collide. In particular the performance of inserting N
elements into a hashtable can degrade from O(N) to O(N^2) using carefully
chosen keys.

A very simple demo script for creating a hashtable with many collisions:

$s = 1 << 16; $a = [];
for ($i = 0; count($a) < $s; $i += $s) { $a[$i] = 0; }

This code creates an array with about 65k elements and runs in 30s (PHP
5.6) or 4s (PHP 7) on my machine.

This behavior can be exploited by an attacker whenever a server running PHP
can be made to create a decent-sized array (or object) with
attacker-controlled keys. This DOS vulnerability is efficient: A 700kb
payload can easily take 5 CPU seconds to process on PHP 7 and from there it
goes up quadratically (i.e. 1.4MB payload takes 20 seconds etc).

The most obvious attack vector are GET and POST variables, which are
automatically decoded into arrays. PHP 5.3.9 prevented this attack avenue
by introducing max_input_vars, which prevents creating GET/POST arrays with
more than a certain number of elements. As the HashDos attack relies on
O(N^2) asymptotic runtime, limiting N to small numbers is an effective fix.

However, GET/POST are not the only ways an attacker can trigger
array/object creation with specific keys. For example many PHP applications
have endpoints that accept JSON encoded payloads, which are not protected
by max_input_vars. The only means of protection currently available to
userland code is to never decode JSON payloads that exceed some
conservative size limit like 50-100KB (often not practical).

Apart from JSON, there will likely be various other application-specific
situations where arrays are generated which contain user-provided keys.
While we could add something similar to max_input_vars to json_decode and
unserialize, this would not solve the problem for any custom code.

There are essentially three ways to prevent HashDos attacks in general
(rather than patching specific places):

1. If there are many collisions for a hash slot, switch collision
resolution from linked lists to self-balancing binary trees.
2. Switch hashtables to a keyed cryptographic hash like SipHash.
3. If there are very many collisions for a hash slot, throw a fatal error.

I will comment on these possibilities as they apply to PHP.

1. (Self-balancing binary trees). The idea here is that a balanced binary
tree has worst-case insertion time O(log N), while the linked list we
normally use has worst-case insertion time O(N). This means that the
worst-case execution time for N insertions into a hashtable goes from
O(N^2) to O(N log N), i.e. from catastrophic to "a few times slower than
usual".

I don't think this solution is viable for PHP. Supporting binary trees next
to linked list collision resolution will make the hashtable implementation
*a lot* more complicated -- and it isn't exactly simple as is.

2. (Randomized cryptographic hash). This approach doesn't change anything
about how collisions are handled, instead it prevents the attacker from
constructing such collisions in the first place.

This is done by using a fast cryptographic hash function (typically
SipHash), which is keyed with a (cryptographically strong) random key. As
the attacker does not know the key, he cannot efficiently construct arrays
with many collisions.

There are a number of factors to take into account when trying to apply
this to PHP:

a) The SipHash key would have to be the same for all processes in an FPM
pool. We can't use a per-process or per-request key due to arrays living in
opcache SHM. As far as I know SipHash is designed to be secure even when
the used key is long living, so this does not appear to be an issue.

b) SipHash is slower (especially for very small strings) than the hash
function we currently use (DJBX33A). As PHP 7 caches the hashes for
strings, I do not believe this to be a significant problem.

c) The real issue: Currently PHP does not hash integer keys, but they are
just as susceptible to 

Re: [PHP-DEV] HashDos protection

[Niklas Keller]

>
> 3. (Fatal error on many collisions). While the two previous options try to
> ensure that hashtables stay efficient regardless of the used keys, the last
> option aims to simply detect malicious array keys and abort the script in
> such a case.
>
> This is done by counting the number of collisions during hashtable
> insertion operations and throwing a fatal error if this collisions count
> exceeds a certain threshold.
>

Would this be a catchable Error (implementing Throwable) or a real fatal?
Having a real fatal could lead to a DOS in Aerys as you'd be able to crash
workers with carefully crafted input variables then.

Thanks, Niklas

[PHP-DEV] PHP 5.6.16 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP
5.6.16. Several
bugs have been fixed. All PHP 5.6 users are encouraged to upgrade to this
version.

For source downloads of PHP 5.6.16 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.16

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

php-5.6.16.tar.bz2
SHA256 hash:
4fe6f40964c1bfaba05fc144ba20a2cdad33e11685f4f101ea5a48b98bbcd2ae
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWVkiJAAoJEMK/C8Qzz8iznBAH/0Vvif1+NM+G1QSiuvEvfTDa
kTaGSmaKZA2BkeVPLLC3Wphwh7w95jjm1LNSZsNoHeqOt1C89HkoTbJpyo8B1U10
xoKGaQ7X7ZtMndRn4/PBXvkIq+ttxo4a/v+X9ifUeMDa+bwZlfV1JTLO8wXX6DMU
c1s7YV5Q0HAKBAW7as8fO06cDx/yVBRdoH1FQgJvNwUqfwnGQ5iTzzu0PvahUoP1
jQapoY9e/2d6SB8AXY8k3uPrwZH5wp1iKo0MS3z1zL4X5e/tL5czwBPOK+iydxJQ
ifHGQ3RXjjH+4Y1vbj47WHcJauT3LdUXdFaRHnuuCEa7BPu71vYaKSZBhiItB7g=
=OWmb
-END PGP SIGNATURE-

php-5.6.16.tar.gz
SHA256 hash:
b6618df6b11a275fa28596f1775727679f8492e100f3bd488d8a8bfbfc19349f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWVkiPAAoJEMK/C8Qzz8izYCkH/jKlOgZaFMUJm5Dk0lsyzuWv
591KWzc35P1UTMA6FmcPFIHf1pf+YMBWRmf9eIwRWE7iPfkDo1Dgl+w1Rnyntf7P
rarUBF/uz9UmPTHs1Yi/XFdPCGZFHBdzELqjGIZUdnHayPoCgV0SlfJnWC0kRTM2
TkxfnOKWWvp28KEyRyP5gJgmz45Elt2UKDVOCQGetTi/rGbW11QjGbAI/zFP7Opm
hnLyhcn4pqOxxaRTScDsDqSa3QwyfE7Lz8uF+U9ES6NGzsM2wDd3D0n3CY25l3I7
wccX7KBSaEygaHJQ4CoATyZSLrHccwvd8vfFBtgjIvU0vHBTy2Nc5W9FuRPUex4=
=CS+h
-END PGP SIGNATURE-

php-5.6.16.tar.xz
SHA256 hash:
8ef43271d9bd8cc8f8d407d3ba569de9fa14a28985ae97c76085bb50d597de98
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWVkiUAAoJEMK/C8Qzz8iz54oH/0ymimqFb/RiNKkXex4Aizl4
Gqu+oIERXXyi0nGizhmP+OjJzrG6pakdigf9ZZqz2m1lKQiNnA50Ksd5o2hdaJW0
UNl61cjqclNMSaAEvVsabfuR7xohvaR8BydavCigIagNvcoiZvxZUpCeU0slrRM5
TfWVr6gxB3u0u/9HJBAwKoKqW9I17BDqz7IAKUCpM/c+0m7XrUHuFeJqDBexJZ8O
fchCESOivcU0sC7le3hziKw1UI9a3SyHSda2MsB0eZvC5ujcS6k98faXefkTSzrc
qYAAqUuRuY8xrnhkVNunEod/Wun/MwY980hfTMXvtVUgzv5rVo8uBrGQXf5+Fu8=
=om+M
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] Re: HashDos protection

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 26/11/2015 18:24, Nikita Popov a écrit :

> Here is an implementation of this mechanism for PHP: 
> https://github.com/php/php-src/pull/1565
> 
> This is the approach I would recommend for PHP. The patch for this 
> change is small and non-intrusive and does not break ABI. From my 
> testing it has no adverse performance impact. (In microbenchmarks
> I found it to even be consistently faster, as it uses a more
> specialized implementation for a commonly used type of insertion
> operation.)

Thanks for this work.

I agree, this seems a very acceptable solution, I would also recommend
it, even for 7.0.1 (perhaps even for 5.6 if possible)


Remi.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlZYA18ACgkQYUppBSnxahg7pQCeNCpRjQxdzZz9MXF94snPsigB
nxwAn0lK0VAZgn5u4n+S1C1ABlvRrRWU
=otYB
-END PGP SIGNATURE-

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