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

[Stanislav Malyshev]

Hi!

> You may try to replace attribute syntax with @attr(...) (without
> semicolon) into our PHP parser.
> Note that we have LALR grammar + restrictions caused by semantic actions.
> If you are able to do this, I'll add it into the RFC as an option.

I'll try if I have time soon.

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

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

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

[Marco Pivetta]

Hey Lester,

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.
On Apr 27, 2016 13:47, "Lester Caine"  wrote:

On 25/04/16 20:24, Rasmus Schultz wrote:
> Check here to see what we did for php-annotations:
>
>
https://github.com/php-annotations/php-annotations/blob/master/docs/CustomAnnotations.rst#usageannotation
>
> It's somewhat similar to how C# does it, and it has worked quite nicely.

After some fun caused by the way projects keep getting rewritten to
comply with the latest undemocratic changes to coding style, I have a
copy of php-annotations working without composer and what is imediatly
obvious is that current PHPDoc standard could do with an update.

php-annotations has some nice extensions such as range and length, but
these have been culled from the current builds because they are not part
of the standard. The problem is of cause that phpdoc.org are now
defining that standard and applying their view of how code should be
written, and the tags no longer align with much of the legacy code,
which is why we still have the phpDocumentor1 versions being used.

docBloc annotation IS well established, but can we at least document a
core PHP view of what should be available, and how to extend that to
support the alternat tags people are looking for.

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

[PHP-DEV] [RFC] Intersection Types

[Levi Morrison]

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

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

[Pierrick Charron]

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  >;
> > 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  > 
> >   >  > >
> > 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  > 
> >
> >   > 
> > >;
> > 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 without any further
> logic. If
> > there were
> >   > a reduced patch with only such cases, it would be acceptable for
> 7.0
> > as well and
> >   > there were probably no collisions expected. What do you think?
> >   >
> >
> >   So far I understood tests are exactly about HTTP2. Not sure how you
> > would tests all the constants present in libcurl. Would need to rebuild
> with a
> > dozen libcurl versions, but the documentation and compile time version
> check
> > are already reliable things.
> >
> But if you can fish out only the cases with name/value which don't
> interfere with the HTTP2 work, so it's fine to add. OFC it were absurd to
> recompile with all libcurl versions :) especially as an excellent
> 

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

[Pierrick Charron]

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 > > 
>> >   >  >
>> >
>> > 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 > > 
>> >
>> >   > 
>> > >;
>> > 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 without any further
>> logic. If
>> > there were
>> >   > a reduced patch with only such cases, it would be acceptable
>> for 7.0
>> > as well and
>> >   > there were probably no collisions expected. What do you think?
>> >   >
>> >
>> >   So far I understood tests are exactly about HTTP2. Not sure how
>> you
>> > would tests all the constants present in libcurl. Would need to rebuild
>> with a
>> > 

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

[Lester Caine]

On 27/04/16 21:11, Fleshgrinder wrote:
> It is about natural language, proper computer
> science terminology, and what PHP users will search for in search
> engines.

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?

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.

-- 
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] [RFC] PHP Annotations VS Attributes

[Michał Brzuchalski]

2016-04-27 22:53 GMT+02:00 Niklas Keller :

> Fleshgrinder  schrieb am Mi., 27. Apr. 2016 22:11:
>
> > I am writing this in a separate thread because of the urgency that I see
> > regarding the naming of past, current, and future proposals regarding
> > this functionality.
> >
> > It was and is proposed to create this feature with the name *Attributes*
> > as Facebook did in their Hack language. Main argument is to blindly
> > follow /because/.
> >
> > On 4/25/2016 10:31 AM, Dmitry Stogov wrote:
> > > Different languages names this differently.
> > > I may add an additional voting question - "annotation vs attributes?".
> > >
> >
> > It is true and only natural that different languages choose different
> > names for equivalent features but this discussion is not about taste,
> > style, nor coolness. It is about natural language, proper computer
> > science terminology, and what PHP users will search for in search
> > engines. I already tried to explain this in the actual thread but I
> > guess my attempts resulted in more confusion than clarification, let me
> > try again.
> >
> >  ATTRIBUTE 
> >
> > The word *attribute* has several meanings in computer science and this
> > is mainly due to its extremely generic nature:
> >
> > > a usually good quality or feature that someone or something has
> > >
> > > --- http://www.merriam-webster.com/dictionary/attribute
> >
> > > In computing, an attribute is a specification that defines a property
> > > of an object, element, or file. [...] For clarity, attributes should
> > > more correctly be considered metadata. An attribute is frequently and
> > > generally a property of a property.
> > >
> > > --- https://en.wikipedia.org/wiki/Attribute_%28computing%29
> >
> > This pretty much sums it up already. An attribute is the metadata that
> > is attached to an element of source code. This metadata is anything
> > unessential that is additionally added but not necessarily required.
> >
> >   class A {
> > var $x;
> >   }
> >
> > The `class` and `var` keywords are essential in this example and define
> > the actual element and the names are required too.
> >
> >   public final class A {
> > private static int $x = 42;
> >   }
> >
> > Class A has the attributes `public` and `final`.
> > Property `$x` has the attributes `private`, `static`, `int`, and `42`.
> >
> > All of these attributes of the class and the property add additional
> > metadata to the source code elements that define their qualities or
> > features and consequently their behavior and usage.
> >
> > http://www.onelook.com/?w=attribute=a
> > http://encyclopedia2.thefreedictionary.com/attribute
> >
> > Sebastian Bergmann already explained this but I think it is important to
> > be repeated and further clarified. The word attribute is often used to
> > refer to properties with additional metadata (e.g. access modifiers,
> > default values, ...; illustrated above) in an OO context. This makes the
> > usage of the word attribute additionally to its generic nature ambiguous
> > as well:
> >
> > https://en.wikipedia.org/wiki/Attribute_%28computing%29
> >
> > http://encyclopedia2.thefreedictionary.com/instance+attribute
> > https://en.wikipedia.org/wiki/Instance_variable
> >
> > http://encyclopedia2.thefreedictionary.com/static+attribute
> > https://en.wikipedia.org/wiki/Static_variable
> >
> > *All* userland implementations that are called /attributes/ in the free
> > and open world deal with completely different things:
> >
> > https://packagist.org/search/?q=attribute
> >
> > 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
> >
> >  ANNOTATION 
> >
> > > Extra information associated with a particular point in a document or
> > > program. Annotations may be added either by a compiler or by the
> > > programmer. They are not usually essential to the correct function of
> > > the program but give hints to improve performance.
> > >
> > > --- http://encyclopedia2.thefreedictionary.com/annotation
> >
> > http://www.onelook.com/?w=annotation=a
> >
> > The term *annotation* is not only used by Java:
> >
> > https://packagist.org/search/?q=annotation
> >
> > https://en.wikipedia.org/wiki/Annotation
> > https://en.wikipedia.org/wiki/Ruby_character
> > https://en.wikipedia.org/wiki/Java_annotation
> >
> > https://msdn.microsoft.com/en-us/library/dd901590%28VS.95%29.aspx
> > http://docs.scala-lang.org/tutorials/tour/annotations.html
> > https://kotlinlang.org/docs/reference/annotations.html
> > https://www.python.org/dev/peps/pep-3107/
> > https://ghc.haskell.org/trac/ghc/wiki/Annotations
> > http://ceylon-lang.org/documentation/1.2/tour/annotations/
> >
> http://clojure-doc.org/articles/ecosystem/core_typed/start/annotations.html
> > 

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

[Rasmus Schultz]

> In this case I would suggest to use class A which leaves room open 
> to define lower bounds later on

IMHO that is bordering on unreadable - all those brackets are really confusing
and hard on the eyes.

Either way, using : does not prevent us from adding lower bounds later
on - but even
then, upper bound is the 99% use case, so I don't think it makes sense to design
the syntax around a possible future upper bound.

If we do support it in the future, I don't think anyone's going to
care what it looks like,
as it's unlikely most people will ever encounter it or need it.


On Tue, Apr 26, 2016 at 10:15 PM, Robert Stoll  wrote:
>
>
>> -Ursprüngliche Nachricht-
>> Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
>> Gesendet: Montag, 25. April 2016 18:09
>> An: Josh Di Fabio
>> Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben Scholzen 
>> 'DASPRiD'; Sara Golemon; PHP internals; Mathieu
>> Rochette
>> Betreff: Re: [PHP-DEV] [RFC:generics]
>>
>> > I really don't like 'as' in this context, even if Hack uses it, as it
>> > doesn't reflect in English terms what the code is doing. As others
>> > have already said, it reads as if 'T' is being aliased to 'Bar'.
>>
>> I second that.
>>
>> I hear the concerns about adding another reserved word "is" though, so I'd 
>> like to suggest simply using a ":" ... as in:
>>
>> class A { ... }
>
> In this case I would suggest to use class A which leaves room open 
> to define lower bounds later on (either with <: as well or with :> as in 
> scala)
>
>>
>> Consistent with return type-hints, it should feel like home?
>>
>> For sure nobody wants to type out "instanceof", and (as pointed out in the 
>> RFC) the instanceof operator checks the type of
>> an object, which is *not* what this is doing - a type argument is not an 
>> "instance of" anything. The ":" is more neutral in that
>> regard maybe?
>>
>>
>> On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio  
>> wrote:
>> > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
>> >  wrote:
>> >> Thanks for you're input everyone.
>> >>
>> >> So far, we have read some ideas for handling upper bounds, or
>> >> multiple there of.
>> >> The preferred keywords appear to be either "as" or "instanceof".
>> >>
>> >> class Foo {}
>> >> class Foo {}
>> >>
>> >> We would like to know for sure then if everyone is largely against
>> >> the addition of an "is" keyword, in favour of one of the other two.
>> >>
>> >
>> > I really don't like 'as' in this context, even if Hack uses it, as it
>> > doesn't reflect in English terms what the code is doing. As others
>> > have already said, it reads as if 'T' is being aliased to 'Bar'.
>> >
>> > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
>> >  wrote:
>> >> Thanks for you're input everyone.
>> >>
>> >> So far, we have read some ideas for handling upper bounds, or
>> >> multiple there of.
>> >> The preferred keywords appear to be either "as" or "instanceof".
>> >>
>> >> class Foo {}
>> >> class Foo {}
>> >>
>> >> We would like to know for sure then if everyone is largely against
>> >> the addition of an "is" keyword, in favour of one of the other two.
>> >>
>> >> 
>> >>
>> >> There is also a desire to include unions and intersections.
>> >> Presently though, this feature feels tied in with
>> >> https://wiki.php.net/rfc/union_types meaning if union types are
>> >> approved, then generics would have to support them as well.  Likewise
>> >> if this feature becomes approved in generics, it would make sense to
>> >> support them in regular type hints as well.
>> >>
>> >> 
>> >>
>> >> The RFC makes a reference to generic closures, which may look
>> >> something like
>> >> this:
>> >>
>> >> function my_function(callable $func) {
>> >>
>> >> }
>> >>
>> >> However, an RFC already exists which is very similar to this feature
>> >> at https://wiki.php.net/rfc/callable-types
>> >> As it currently standards these RFCs appear incompatible with each
>> >> other (please correct me if I am wrong).
>> >>
>> >> My question about this is would you prefer the generics RFC exclude
>> >> this part in favour of a separate or later RFC.
>> >> Initially the proposal included generic arrays "array".
>> >> However to ease the implementation it was decided that should be a 
>> >> separate feature.
>> >> So we'd like to find out if everyone else feels the same way about
>> >> callable types.
>> >>
>> >> 
>> >>
>> >> This RFC currently doesn't specify in detail how reflection would
>> >> work.  We have attempted a few API designs, but due to generic classes 
>> >> being ...
>> >> generic, it is difficult to find a suitable way to glean information
>> >> about a class in a backwards compatible manner.  So we will need some
>> >> help on this one.
>> >>
>> >> -
>> >>
>> >> Aside from these top issues on our own list, however does everyone
>> >> 

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

[Rasmus Schultz]

Thanks Guilherme - this pretty much sums up how I feel about features 2-5.

Plain generics with upper bounds, I find some case where it's missing,
almost daily.

As for the gist you posted, I'm lost, what does this have to do with reflection?


On Tue, Apr 26, 2016 at 10:50 PM, guilhermebla...@gmail.com
 wrote:
> Hi all,
>
> Yesterday I spent a considerable 2h talking about Generics in Doctrine
> channel.
> We discussed the specifics of each boundary that PHP's implementation could
> take advantage. Here are our findings, which I'll illustrate using Java
> equivalents:
>
> 1- Upper bounds (T extends A)
>
> We all understood they're required. Whenever you mention class Foo
> {}, we're talking that T can be A or any of its subtypes.
> Also, we debated over intersection types. It's an edge case, and its support
> could be done as a subsequent RFC once union and intersection types gets
> resolved.
>
> 2- Lower bounds (T super A)
>
> It was just not possible to come up with a single use case or possibility.
> It not only violates Liskov, but it also doesn't make any sense in the
> context of PHP.
> When we debate about Java, it does make sense because of polymorphism and
> the requirement removal of implementing multiple methods.
>
> 3- Unbounded wildcards (?)
>
> It wouldn't be necessary in the context of PHP. Why?
> Once we introduce Generics, the difference between process(List $list) and
> process(List $list) would be none, as due to PHP's nature.
>
> 4- Upper bounded wildcard (? extends A)
>
> Again, invalid in the context of PHP. Let me explain why...
> In Java context, whenever you declare something as List, you can only add
> As to the list, but no subtypes. When you declare List, you can
> add A and also any of its subtypes.
> PHP is loose in this restriction, so there's no way of strict-ing to only A
> but not subtypes. Defining as List would be enough, and PHP wouldn't
> support adding A and A only.
>
> 5- Lower bounded wildcard (? super A)
>
> Applies the same concept of #2. PHP doesn't need it as it doesn't fully
> support polymorphism.
>
> 6- Reflection
>
> We discussed over an example I extracted from a piece of code I currently
> work on. We came with several ideas, but couldn't wrap up (but we're 80%) a
> valid approach. The example we debated was this one:
> https://gist.github.com/guilhermeblanco/56ec0e11e7b029c2cfdcaf6fe2323742
>
>
>
>
> So I'll have to say sorry for poking around of "missing implementation"
> while in reality most of them cannot be applied in the context of PHP.
> I've reviewed the RFC again and it mostly makes sense surrounding
> boundaries. I still have to talk about diamond operator and constructor
> generic type.
>
>
> []s,
>
>
> On Tue, Apr 26, 2016 at 4:15 PM, Robert Stoll  wrote:
>>
>>
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
>> > Gesendet: Montag, 25. April 2016 18:09
>> > An: Josh Di Fabio
>> > Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben Scholzen
>> > 'DASPRiD'; Sara Golemon; PHP internals; Mathieu
>> > Rochette
>> > Betreff: Re: [PHP-DEV] [RFC:generics]
>> >
>> > > I really don't like 'as' in this context, even if Hack uses it, as it
>> > > doesn't reflect in English terms what the code is doing. As others
>> > > have already said, it reads as if 'T' is being aliased to 'Bar'.
>> >
>> > I second that.
>> >
>> > I hear the concerns about adding another reserved word "is" though, so
>> > I'd like to suggest simply using a ":" ... as in:
>> >
>> > class A { ... }
>>
>> In this case I would suggest to use class A which leaves room
>> open to define lower bounds later on (either with <: as well or with :> as
>> in scala)
>>
>> >
>> > Consistent with return type-hints, it should feel like home?
>> >
>> > For sure nobody wants to type out "instanceof", and (as pointed out in
>> > the RFC) the instanceof operator checks the type of
>> > an object, which is *not* what this is doing - a type argument is not an
>> > "instance of" anything. The ":" is more neutral in that
>> > regard maybe?
>> >
>> >
>> > On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio 
>> > wrote:
>> > > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
>> > >  wrote:
>> > >> Thanks for you're input everyone.
>> > >>
>> > >> So far, we have read some ideas for handling upper bounds, or
>> > >> multiple there of.
>> > >> The preferred keywords appear to be either "as" or "instanceof".
>> > >>
>> > >> class Foo {}
>> > >> class Foo {}
>> > >>
>> > >> We would like to know for sure then if everyone is largely against
>> > >> the addition of an "is" keyword, in favour of one of the other two.
>> > >>
>> > >
>> > > I really don't like 'as' in this context, even if Hack uses it, as it
>> > > doesn't reflect in English terms what the code is doing. As others
>> > > have already said, it reads as if 'T' is being aliased to 'Bar'.
>> > >
>> > > On 

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

[Niklas Keller]

Fleshgrinder  schrieb am Mi., 27. Apr. 2016 22:11:

> I am writing this in a separate thread because of the urgency that I see
> regarding the naming of past, current, and future proposals regarding
> this functionality.
>
> It was and is proposed to create this feature with the name *Attributes*
> as Facebook did in their Hack language. Main argument is to blindly
> follow /because/.
>
> On 4/25/2016 10:31 AM, Dmitry Stogov wrote:
> > Different languages names this differently.
> > I may add an additional voting question - "annotation vs attributes?".
> >
>
> It is true and only natural that different languages choose different
> names for equivalent features but this discussion is not about taste,
> style, nor coolness. It is about natural language, proper computer
> science terminology, and what PHP users will search for in search
> engines. I already tried to explain this in the actual thread but I
> guess my attempts resulted in more confusion than clarification, let me
> try again.
>
>  ATTRIBUTE 
>
> The word *attribute* has several meanings in computer science and this
> is mainly due to its extremely generic nature:
>
> > a usually good quality or feature that someone or something has
> >
> > --- http://www.merriam-webster.com/dictionary/attribute
>
> > In computing, an attribute is a specification that defines a property
> > of an object, element, or file. [...] For clarity, attributes should
> > more correctly be considered metadata. An attribute is frequently and
> > generally a property of a property.
> >
> > --- https://en.wikipedia.org/wiki/Attribute_%28computing%29
>
> This pretty much sums it up already. An attribute is the metadata that
> is attached to an element of source code. This metadata is anything
> unessential that is additionally added but not necessarily required.
>
>   class A {
> var $x;
>   }
>
> The `class` and `var` keywords are essential in this example and define
> the actual element and the names are required too.
>
>   public final class A {
> private static int $x = 42;
>   }
>
> Class A has the attributes `public` and `final`.
> Property `$x` has the attributes `private`, `static`, `int`, and `42`.
>
> All of these attributes of the class and the property add additional
> metadata to the source code elements that define their qualities or
> features and consequently their behavior and usage.
>
> http://www.onelook.com/?w=attribute=a
> http://encyclopedia2.thefreedictionary.com/attribute
>
> Sebastian Bergmann already explained this but I think it is important to
> be repeated and further clarified. The word attribute is often used to
> refer to properties with additional metadata (e.g. access modifiers,
> default values, ...; illustrated above) in an OO context. This makes the
> usage of the word attribute additionally to its generic nature ambiguous
> as well:
>
> https://en.wikipedia.org/wiki/Attribute_%28computing%29
>
> http://encyclopedia2.thefreedictionary.com/instance+attribute
> https://en.wikipedia.org/wiki/Instance_variable
>
> http://encyclopedia2.thefreedictionary.com/static+attribute
> https://en.wikipedia.org/wiki/Static_variable
>
> *All* userland implementations that are called /attributes/ in the free
> and open world deal with completely different things:
>
> https://packagist.org/search/?q=attribute
>
> 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
>
>  ANNOTATION 
>
> > Extra information associated with a particular point in a document or
> > program. Annotations may be added either by a compiler or by the
> > programmer. They are not usually essential to the correct function of
> > the program but give hints to improve performance.
> >
> > --- http://encyclopedia2.thefreedictionary.com/annotation
>
> http://www.onelook.com/?w=annotation=a
>
> The term *annotation* is not only used by Java:
>
> https://packagist.org/search/?q=annotation
>
> https://en.wikipedia.org/wiki/Annotation
> https://en.wikipedia.org/wiki/Ruby_character
> https://en.wikipedia.org/wiki/Java_annotation
>
> https://msdn.microsoft.com/en-us/library/dd901590%28VS.95%29.aspx
> http://docs.scala-lang.org/tutorials/tour/annotations.html
> https://kotlinlang.org/docs/reference/annotations.html
> https://www.python.org/dev/peps/pep-3107/
> https://ghc.haskell.org/trac/ghc/wiki/Annotations
> http://ceylon-lang.org/documentation/1.2/tour/annotations/
> http://clojure-doc.org/articles/ecosystem/core_typed/start/annotations.html
> https://www.dartlang.org/effective-dart/style/
> ...
>
> https://rubygems.org/search?utf8=%E2%9C%93=annotation
> http://rustbyexample.com/scope/lifetime/explicit.html
> https://www.google.de/search?q=javascript+annotation
> ...
>
> Ignoring these facts just because Facebook did not do proper research is
> a total no go. It is also not up 

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

[Fleshgrinder]

I am writing this in a separate thread because of the urgency that I see
regarding the naming of past, current, and future proposals regarding
this functionality.

It was and is proposed to create this feature with the name *Attributes*
as Facebook did in their Hack language. Main argument is to blindly
follow /because/.

On 4/25/2016 10:31 AM, Dmitry Stogov wrote:
> Different languages names this differently.
> I may add an additional voting question - "annotation vs attributes?".
>

It is true and only natural that different languages choose different
names for equivalent features but this discussion is not about taste,
style, nor coolness. It is about natural language, proper computer
science terminology, and what PHP users will search for in search
engines. I already tried to explain this in the actual thread but I
guess my attempts resulted in more confusion than clarification, let me
try again.

 ATTRIBUTE 

The word *attribute* has several meanings in computer science and this
is mainly due to its extremely generic nature:

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

> In computing, an attribute is a specification that defines a property
> of an object, element, or file. [...] For clarity, attributes should
> more correctly be considered metadata. An attribute is frequently and
> generally a property of a property.
>
> --- https://en.wikipedia.org/wiki/Attribute_%28computing%29

This pretty much sums it up already. An attribute is the metadata that
is attached to an element of source code. This metadata is anything
unessential that is additionally added but not necessarily required.

  class A {
var $x;
  }

The `class` and `var` keywords are essential in this example and define
the actual element and the names are required too.

  public final class A {
private static int $x = 42;
  }

Class A has the attributes `public` and `final`.
Property `$x` has the attributes `private`, `static`, `int`, and `42`.

All of these attributes of the class and the property add additional
metadata to the source code elements that define their qualities or
features and consequently their behavior and usage.

http://www.onelook.com/?w=attribute=a
http://encyclopedia2.thefreedictionary.com/attribute

Sebastian Bergmann already explained this but I think it is important to
be repeated and further clarified. The word attribute is often used to
refer to properties with additional metadata (e.g. access modifiers,
default values, ...; illustrated above) in an OO context. This makes the
usage of the word attribute additionally to its generic nature ambiguous
as well:

https://en.wikipedia.org/wiki/Attribute_%28computing%29

http://encyclopedia2.thefreedictionary.com/instance+attribute
https://en.wikipedia.org/wiki/Instance_variable

http://encyclopedia2.thefreedictionary.com/static+attribute
https://en.wikipedia.org/wiki/Static_variable

*All* userland implementations that are called /attributes/ in the free
and open world deal with completely different things:

https://packagist.org/search/?q=attribute

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

 ANNOTATION 

> Extra information associated with a particular point in a document or
> program. Annotations may be added either by a compiler or by the
> programmer. They are not usually essential to the correct function of
> the program but give hints to improve performance.
>
> --- http://encyclopedia2.thefreedictionary.com/annotation

http://www.onelook.com/?w=annotation=a

The term *annotation* is not only used by Java:

https://packagist.org/search/?q=annotation

https://en.wikipedia.org/wiki/Annotation
https://en.wikipedia.org/wiki/Ruby_character
https://en.wikipedia.org/wiki/Java_annotation

https://msdn.microsoft.com/en-us/library/dd901590%28VS.95%29.aspx
http://docs.scala-lang.org/tutorials/tour/annotations.html
https://kotlinlang.org/docs/reference/annotations.html
https://www.python.org/dev/peps/pep-3107/
https://ghc.haskell.org/trac/ghc/wiki/Annotations
http://ceylon-lang.org/documentation/1.2/tour/annotations/
http://clojure-doc.org/articles/ecosystem/core_typed/start/annotations.html
https://www.dartlang.org/effective-dart/style/
...

https://rubygems.org/search?utf8=%E2%9C%93=annotation
http://rustbyexample.com/scope/lifetime/explicit.html
https://www.google.de/search?q=javascript+annotation
...

Ignoring these facts just because Facebook did not do proper research is
a total no go. It is also not up for a vote, it is just proper English
and computer science terminology!

Last but not least, it also ensures that users find the correct PHP
manual page when they search for this new feature that might make it
into core at some point. :)
-- 
Richard "Fleshgrinder" Fussenegger

Re: [PHP-DEV] Re: Request for Karma

[Fleshgrinder]

On 4/27/2016 7:56 PM, Dmitry Stogov wrote:
> Hi Richard,
> 
> I already got help from Pierrick. He is the author of previous RFC 
> https://wiki.php.net/rfc/annotations
> sorry, I have no idea who can give the karma.
> 
> Thanks. Dmitry.
> 

Ah, alright.

Well it says in the HowTo that one needs to send a request to internals
list to ask for karma so somebody knows. I keep the request, I am sure
it will be useful to step in and help on other occasions. :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Fleshgrinder]

On 4/25/2016 10:04 AM, Dmitry Stogov wrote:
> 
> 
> On 04/24/2016 11:24 AM, Fleshgrinder wrote:
>> The invariant could also be added as an additional branch to the class
>> instead of a method, since it would not work like a method.
>>
>>class A {} invariant {}
>>
>>function f() {} require {} ensure {}
>>
>> This would also align nicely with closures and anonymous classes, which
>> is kind a problematic with annotations.
>>
>>$A = new class {} invariant {};
>>
>>$f = function () {} require {} ensure {};
>>
>> The only thing that remains that might be of interest to both is
>> `@throws` but that was not discussed at all as of yet.
>>
>>use Ns\SomeException;
>>
>>@throws SomeException
>>function f() {
>>
>>}
>>
>> This is at least how one would expect it to work and it is something
>> that should be covered by annotations and not as part of the language.
>> The ABNF should account for that:
>>
>> ANNOTATION= "@" NAME [ " " VALUE ]
>> NAME  = STRING
>> VALUE = QUOTED-STRING / PHP-REFERENCE / EXPRESSION
>> QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
>> EXPRESSION= PHP-CODE ";"
>>
>> Where PHP references are any of the already possible ones:
>>
>>use F\Q\C\N;
>>
>>@annotation \F\Q\C\N
>>@annotation N
>>@annotation \F\Q\C\N::CONSTANT
>>@annotation N::CONSTANT
>>@annotation \F\Q\C\N::function()
>>@annotation N::function()
>>@annotation \F\Q\C\N::$variable
>>@annotation N::$variable
>>
>> I also though some more about function support for annotations and this
>> would actually be a nice thing for userland.
>>
>>annotation deprecated(Reflection $element, string $message = '') {
>>  @trigger_error($message, E_USER_DEPRECATED);
>>}
>>
>>@deprecated('because')
>>function x() {}
>>
>>@deprecated
>>function y() {}
>>
>> This would allow users to implement simple and easy reactive annotations
>> in userland. Even if this could or should be an extension of the feature
>> in the future, it should be thought about know. Simply because the
>> brackets make sense if such a feature is to be implemented. ;)
>>
> Looks interesting, but try to think where the "annotation deprecated"
> should be declared,to be visible in every compiled script, when the
> corresponding code should be called (in what context), what if we need
> to do something at compile-time? Single answers to these question are
> going to be great for "deprecated" use case, however they will limit
> usability for other cases.
> 
> Thanks. Dmitry.
> 

Reactive annotations would have their limitations, e.g. calls to the
reactive annotation function only happen during runtime and any attempts
to perform something at compile time directly results in an engine
error. It limits their use cases but allows interesting ones at the same
time.

Another approach could be to allow registration of reactive annotation
functions at runtime, this would make it even more useful. Of course
that would mean that the function is only called for each encountered
annotation at runtime after it was registered. However, such a
limitation is pretty much the same as we have it for any other function
right now too.

  class User {

public function hasRole($right) {
  if (false) {
throw new InsufficientPrivileges;
  }
}

  }

  $user = new User();

  register_annotation('Framework\Role', [ $user, 'hasRole' ]);

  class Controller {

@Framework\Role('admin') public function editAction(){}

  }

  // ENGINE (pseudo code)

  array registered_annotations = [];

  void register_reactive_annotation(annotation, callback)
  {
registered_annotations[annotation] = callback;
  }

  void reactive_annotation_call(annotation, ...arguments)
  {
if (annotation exists in registered_annotations) {
  call registered_annotations[annotation](...arguments);
}
else {
  log_info("Unknown reactive annotation %s", annotation);
}
  }

However, this is a story for another RFC. It is only important because
usage of the brackets in the current RFC would make such a feature more
complicated to implement.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [VOTE] Square bracket syntax for array destructuring assignment

[Andrea Faulds]

Hi everyone,

The RFC "Square bracket syntax for array destructuring assignment" has 
had 20 days to be discussed so far, and there don't seem to be any 
remaining issues with it.


So, we're putting it to a vote.

Voting starts today, 2016-04-27, and ends on the Sunday after next, 
2016-05-08. It's a 2/3 majority vote, as it's a language change. The 
intent is to have this in PHP 7.1.


The RFC, which contains the voting widget, can be found here:

https://wiki.php.net/rfc/short_list_syntax

Please consider voting.

Thanks!
--
Andrea Faulds
https://ajf.me/

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

[PHP-DEV] Re: Request for Karma

[Dmitry Stogov]

Hi Richard,

I already got help from Pierrick. He is the author of previous RFC 
https://wiki.php.net/rfc/annotations
sorry, I have no idea who can give the karma.

Thanks. Dmitry.


From: Fleshgrinder 
Sent: Wednesday, April 27, 2016 20:34
To: php-internals
Cc: Dmitry Stogov
Subject: Request for Karma

Hello fellows!

I would like to request karma for the PHP wiki to support others in
writing RFCs and maybe some time in the future contribute RFCs. For now
I plan to help Dmitry Stogov as co-author with the already existing
Attributes RFC.

A few words about my person might not hurt I guess. I am an MSc and PHP
developer from Austria. I work with PHP since many years, however, I am
also fluent in Java, JavaScript, Shell, ... and know my ways around in
C, C++, Rust, ... I am currently working at trivago in Germany as lead
PHP developer of a small development team.

I already registered a wiki account under the name "fleshgrinder".
--
Richard "Fleshgrinder" Fussenegger


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

[PHP-DEV] Request for Karma

[Fleshgrinder]

Hello fellows!

I would like to request karma for the PHP wiki to support others in
writing RFCs and maybe some time in the future contribute RFCs. For now
I plan to help Dmitry Stogov as co-author with the already existing
Attributes RFC.

A few words about my person might not hurt I guess. I am an MSc and PHP
developer from Austria. I work with PHP since many years, however, I am
also fluent in Java, JavaScript, Shell, ... and know my ways around in
C, C++, Rust, ... I am currently working at trivago in Germany as lead
PHP developer of a small development team.

I already registered a wiki account under the name "fleshgrinder".
-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Anatol Belski]

> -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 ;
> 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  
>   >  > >
> 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  
> 
>   >  > >;
> 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 without any further logic. If
> there were
>   > a reduced patch with only such cases, it would be acceptable for 7.0
> as well and
>   > there were probably no collisions expected. What do you think?
>   >
> 
>   So far I understood tests are exactly about HTTP2. Not sure how you
> would tests all the constants present in libcurl. Would need to rebuild with a
> dozen libcurl versions, but the documentation and compile time version check
> are already reliable things.
> 
But if you can fish out only the cases with name/value which don't interfere 
with the HTTP2 work, so it's fine to add. OFC it were absurd to recompile with 
all libcurl versions :) especially as an excellent documentation to every 
option is presend on the cURL side. If that's only an option that say affects 
the curl behavior and don't require any extra handling, I don't think it is 
critical. On the other hand, if an option requires some pre/post handling an 
thus some extra implementation - then OFC it should be urgently suggested to 
have a good test.

Thanks

Anatol


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

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

[Pierrick Charron]

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  >  > 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  >  >; paj...@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 without any further logic. If
> there were
> > a reduced patch with only such cases, it would be acceptable for 7.0 as
> well and
> > there were probably no collisions expected. What do you think?
> >
> So far I understood tests are exactly about HTTP2. Not sure how you would
> tests all the constants present in libcurl. Would need to rebuild with a
> dozen libcurl versions, but the documentation and compile time version
> check are already reliable things.
>
> Thanks
>
> anatol
>
>
>

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

[Anatol Belski]

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   > 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   >; 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 without any further logic. If there 
> were
> a reduced patch with only such cases, it would be acceptable for 7.0 as well 
> and
> there were probably no collisions expected. What do you think?
> 
So far I understood tests are exactly about HTTP2. Not sure how you would tests 
all the constants present in libcurl. Would need to rebuild with a dozen 
libcurl versions, but the documentation and compile time version check are 
already reliable things.

Thanks

anatol



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

Re: [PHP-DEV] [RFC] IntlCharsetDetector

[Tom Worster]

On 4/26/16 12:10 PM, Sara Golemon wrote:

On Tue, Apr 26, 2016 at 2:06 AM, Yasuo Ohgaki  wrote:

Things might have been changed, but as you've mentioned encoding
detection is unstable and ICU is poor compared to mbstring's detection
at least for Japanese encodings.


For me, the difference is that I expect further work to be done on
improving ICU,


Why do you expect that?

When I researched this problem some years ago I had the impression a 
number of attempted solutions had been published and abandoned. I took 
this to mean that there was a learning experience that ended with the 
understanding that it's insoluble.


That's why I'm curious if you know of ongoing efforts in ICU. I took a 
look and saw little activity in the last 10 years.




while I lack that confidence for mbstring.  If the API
is in place early on, the library can improve underneath it to the
point it becomes more trustworthy later, but still be usable on older
versions of PHP (linked against newer libicu).


How would it becomes more trustworthy? A way to make it trustworthy 
would need to exist. And somebody would have to work on it.


Tom


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

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

[Matt Wilmas]

Hi Bogdan, all,

- Original Message -
From: "Andone, Bogdan"
Sent: Monday, April 25, 2016


-Original Message-
From: Andone, Bogdan [mailto:bogdan.and...@intel.com]
Sent: Friday, March 18, 2016 11:58 AM
To: 'Nikita Popov' 
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups

> -Original Message-
> From: Andone, Bogdan [mailto:bogdan.and...@intel.com]
> Sent: Wednesday, March 09, 2016 9:33 AM
> To: 'Nikita Popov'
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups
>
>
>
> > -Original Message-
> > From: Andone, Bogdan [mailto:bogdan.and...@intel.com]
> > Sent: Tuesday, March 08, 2016 4:19 PM
> > To: 'Nikita Popov'
> > Cc: internals@lists.php.net
> > Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups
> >
> > > From: Nikita Popov [mailto:nikita@gmail.com]
> > > Sent: Tuesday, March 08, 2016 3:43 PM
> > > To: Andone, Bogdan
> > > Cc: internals@lists.php.net
> > > Subject: Re: [PHP-DEV] Lazy keys comparison during hash lookups
> > > >On Tue, Mar 8, 2016 at 2:18 PM, Nikita Popov
> > > >
> > wrote:
> > > >> On Tue, Mar 8, 2016 at 2:01 PM, Andone, Bogdan
> > >  wrote:
> > > >> Hi Guys,
> > > >>
> > > >> I would like to propose a small change into the DJBX33A hash
> > function
> > > algorithm which will make easier the key matching validations in
> hash
> > > lookup functions.
> > > >>
> > > >> The change addresses the modulo 8 tailing bytes of the key. For
> > these
> > > bytes we can use an 8 bit shift instead of a 5 bit shift; we also
> need
> > > to replace the ADD by XOR, in order to avoid byte level overflows.
> > This
> > > change ensures the uniqueness of the hash function transformation
> for
> > > the tailing bytes: supposing two strings have same partial hash
> value
> > > for the first Nx8 bytes, different combinations of tailing
> characters
> > > (with the same tail size) will always generate different keys.
> > > >> We have the following consequences:
> > > >> If two strings have:
> > > >> - same hash value,
> > > >> - same length,
> > > >> - same bytes for the first Nx8 positions, then they are equal,
> > > >> and the tailing bytes can be skipped during
> > > comparison.
> > > >>
> > > >> There is a visible performance gain if we apply this approach
> > > >> as
> we
> > > can use a lightweight memcmp() implementation based on longs
> > comparison
> > > and completely free of the complexity incurred by tailing bytes.
> > > For Mediawiki I have a 1.7% performance gain while Wordpress
> > > reports
> 1.2%
> > > speedup on Haswell-EP.
> > > >>
> > > >> Let’s take a small example:
> > > >> Suppose we have a key=”this_is_a_key_value”.
> > > >> The hash function for the first N x 8 byes are computed in the
> > > original way; suppose “this_is_a_key_va” (16bytes) will return a
> > partial
> > > hash value h1; the final hash value will be computed by the
> following
> > > sequence:
> > > >> h = ((h1<<8) ^ h1) ^ ‘l’;
> > > >> h = ((h<<8) ^ h) ^ ‘u’;
> > > >> h = ((h<<8) ^ h) ^ ‘e’;
> > > >> or, in only one operation:
> > > >> h = (h1<<24) ^ (h1<<16) ^ (h1<<8) ^ h1 ^ (‘l’<<16) ^
> ((‘l’^‘u’)<<8)
> > ^
> > > (‘l’^’u’^‘e’)
> > > >> We can see that ht=(‘l’<<16) ^ ((‘l’^‘u’)<<8) ^
> > (‘l’^’u’^‘e’) cannot
> > > be obtained by any other 3 characters long tail. The statement is
> not
> > > true if we use ADD instead of XOR, as extended ASCII characters
> might
> > > generate overflows affecting the LSB of the higher byte in the
> > > hash value.
> > > >>
> > > >> I pushed a pull request here: https://github.com/php/php-
> > > src/pull/1793. Unfortunately it does not pass the travis tests
> because
> > > “htmlspecialchars etc use a generated table that assumes the
> > > current hash function” as noticed by Nikita.
> > > >>
> > > >> Let me know your thoughts on this idea.
> > > >
> > > > Hey Bogdan,
> > > > This looks like an interesting idea! I'm somewhat apprehensive
> about
> > > coupling this to a change of the hash function, for two reasons:
> > > > a) This will make it more problematic if we want to change the
> hash
> > > function in the future, e.g. if we want to switch to SipHash.
> > > > b) The quality of the new hash distribution is not immediately
> > clear,
> > > but likely non-trivially weaker.
> > > > So I'm wondering if we can keep the concept of using a
> > > > zend_ulong
> > > aligned memcmp while leaving the hash function alone: The
> zend_string
> > > allocation policy already allocates the string data aligned and
> padded
> > > to zend_ulong boundaries. If we were to additionally explicitly
> > > zero
> > out
> > > the last byte (to avoid valgrind warnings) we should be able to
> > compare
> > > the character data of two zend_strings using a zend_ulong memcmp.
> This
> > > would have the additional benefit that it works for normal string
> > > comparisons (unrelated to hashtables) as well. On the 

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

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-27 06:28:48+03:00
commit: e88c71d
previous commit:40b2048
revision date:  2016-04-27 00:24:20+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.19%  0.05%  0.94%  
  7.20%
:-|   Drupal 7.36 cgi -T1  0.21%  0.15%  0.48%  
  3.97%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.03%  1.53%  
  3.17%
:-(   bench.php cgi -T100  0.02% -1.16% 24.09%  
  1.06%
:-(  micro_bench.php cgi -T10  0.01% -4.00%  2.61%  
  5.05%
:-|  mandelbrot.php cgi -T100  0.02%  0.22% 30.01%  
  4.19%
---
* Relative Standard Deviation (Standard Deviation/Average)

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

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] Re: ext/curl update

[Pierrick Charron]

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  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 ; 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 without any further logic. If there
> were a reduced patch with only such cases, it would be acceptable for 7.0
> as well and there were probably no collisions expected. What do you think?
>
> Regards
>
> Anatol
>
>

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

[Pierrick Charron]

On 27 April 2016 at 03:27, Dmitry Stogov  wrote:

>
>
> On 04/27/2016 08:25 AM, Pierrick Charron wrote:
>
> Hi all,
>
> First of all thanks dmitry for your great work and for bringing the RFC
> back to life.
>
> I think it would be great to allow users to define their own annotations
> and give them some structure (what the annotation is made of). For example
> let's say I apply an annotation to define that a property is a string with
> a length. In the proposed RFC I will have something like this :
>
> class Foo {
> <>
> public string $bar;
> }
>
> But how could i know for example that StringLength can take an extra
> parameters I would have to read the code of the annotation framework see
> how it parse, use it etc... But if I can define the structure (this is a
> quickly invented pseudo syntax and I'm not proposing it)
>
> annotation MyAnnotation\StringLength {
> private int $length;
> private string $comment = "Default value";
> }
>
> With this definition I know that the Annotation take 2 parameters one int
> and one string, that the comment has a default value and can be omitted
> etc...
>
> Also what I dislike about using a simple array with no definition is that
> you can't annotate an annotation since there is no definition. I know it
> can look complex but think about the power you can add to the system. It
> would help us solve some problems that could not be solved (or at least I
> can't see any way of doing it) if you can't have a definition you can't
> attach behaviour/metadata to it.
>
> Here are some problems we could solve (those are just examples)
>
> 1. Are annotations inhereted or not ? Some will say yes, some now but I
> think they actually both make sense. For example we could imagine that if I
> annotate a method of my interface as deprecated I want it to be inhereted
> because all implementations are, but author annotation should not be
> inherited because I'm not necessarily the author of the implementation. So
> we could say that annotations are by default not inherited and we could
> have an <> annotation
>
> <>
> annotation deprecated {
> }
>
> annotation author {
> public string $name;
> public string $mail;
> }
>
> 2. Is a specific kind of annotation applicable to only one kind of
> statement or multiple ? JIT don't make sense on a property...
>
> <>
> annotation jit {
> }
>
> 3. Current version of the RFC propose that we could either have AST or to
> execute the AST but we could imagine to get both
>
> annotation assert {
> <>
> public ast\node $node;
> public string $message;
> }
>
> Again, this is just a couple of quick ideas, but this would make things
> less magic/obscure with a definition and far more flexible. If we agree
> that we want a definition we could work on how to create this definition
> (we could use some stuff from the old Annotations RFC
> 
> https://wiki.php.net/rfc/annotations?rev=1302087566) to update this one
> with a new syntax or use interface as proposed in the first implementation
>
> class Deprecated implements Annotation {
> }
>
> Maybe
>
>
> didn't you think, that these annotation over-design made your RFC fail?
>

You maybe right, but the RFC was rejected 5 years ago and sometime people
change their mind, that's why I want to get people thought about it as of
today. If people still think the same that's fine with me, I'm just
exposing for people new to it other possibilities.


>
> You can't create objects at compile-time, and should delay their creation
> until Reflection*::getAttributes().
> Returning objects directly form Reflection*::getAttributes() doesn't
> improve flexibility at all.
> This would just increase the complexity of the patch...
>

I agree that this would increase the complexity of the patch but from time
to time we have to do complex things :-) the Zend Engine is full of them
and even if I agree that this should be avoided if possible it's sometime a
necessity. But again this is just my opinion and I'll respect the
community's decision.


>
> As I already said many times, all this extensions are possible to do in
> few PHP lines on top of base functionality.
> See "Doctrine use-case" at https://wiki.php.net/rfc/attributes#use_cases
>
> If you add these extensions directly into PHP implementation in C, you''ll
> have to support them, and you'll always miss some needs for "last
> use-case", but you won't able to change PHP behavior between major PHP
> versions.
>
> Thanks. Dmitry.
>
>
>
> Pierrick
>
>
>

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

[Lester Caine]

On 25/04/16 20:24, Rasmus Schultz wrote:
> Check here to see what we did for php-annotations:
> 
> https://github.com/php-annotations/php-annotations/blob/master/docs/CustomAnnotations.rst#usageannotation
> 
> It's somewhat similar to how C# does it, and it has worked quite nicely.

After some fun caused by the way projects keep getting rewritten to
comply with the latest undemocratic changes to coding style, I have a
copy of php-annotations working without composer and what is imediatly
obvious is that current PHPDoc standard could do with an update.

php-annotations has some nice extensions such as range and length, but
these have been culled from the current builds because they are not part
of the standard. The problem is of cause that phpdoc.org are now
defining that standard and applying their view of how code should be
written, and the tags no longer align with much of the legacy code,
which is why we still have the phpDocumentor1 versions being used.

docBloc annotation IS well established, but can we at least document a
core PHP view of what should be available, and how to extend that to
support the alternat tags people are looking for.

-- 
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] Safe timeout handling

[Matt Wilmas]

Hi Bob, all,

- Original Message 
From: "Bob Weinand"
Sent: Wednesday, April 20, 2016



> Am 20.04.2016 um 18:22 schrieb Dmitry Stogov :
>
>
>
> On 04/20/2016 06:24 PM, Matt Wilmas wrote:
>> Hi Dmitry,
>>
>> - Original Message -
>> From: "Dmitry Stogov"
>> Sent: Wednesday, April 20, 2016
>>
>>> Hi,
>>>
>>>
>>> It's a well known PHP problem, that exceeding of execution time-out
>>> (max_execution_time) may lead to unexpected crashes.
>>>
>>> They occur because PHP may be interrupted in inconsistent state, and 
>>> attempt

>>> to release allocated by request resources leads to failure.
>>>
>>> Almost any big site sees these crashes from time to time.
>>>
>>>
>>> I propose to delay actual request termination until a "safe" point in
>>> interpreter.
>>>
>>> Signal handler will just set EG(timed_out) flag.
>>>
>>> Interpreter will check this time from time to time (on jumps and calls 
>>> that

>>> may make loops or recursion) and perform the actual termination.
>>>
>>> This approach already works in PHP for Windows.
>>
>> I was thinking about this, checking for things like EG(exception) 
>> "constantly," a few months ago for another reason...

>
> This is a bit different problem. We can't delay EG(exception) checks. I 
> thought about a better way of exception handing but didn't find anything 
> usable and portable.

>>
>> What about instead of adding additional checks in the same place(s) in 
>> VM, we just limit it to 1 check, for multiple things? Just have 
>> EG(something_unexpected_to_check), and behind that (or in a function, I 
>> guess), the actual rare/unexpected thing gets checked: timed_out, 
>> exception, etc.

>
> Yes, I have the same idea in background. I even wrote: The same 
> "interrupt" handling mechanism in the future may be reused for TICK

> and signal handling.
>
>>
>> It seems Bob had a similar idea in the PR comment, except literally 
>> using exceptions...

>>
>>> In addition I introduce hard_timeout (default value 2 seconds).
>>>
>>> In case the "soft" timeout wasn't handled "safely" in that 2 seconds
>>> (because of long running internal function), PHP process will be 
>>> terminated

>>> without attempt to free any resources.
>>>
>>> ZTS build will ignore "hard_timeout" (in the same way as PHP on 
>>> Windows do).

>>>
>>>
>>> The PR: https://github.com/php/php-src/pull/1876
>>>
>>>
>>> It removes "exit_on_timeout" ini directive, and introduces 
>>> "hard_timeout"

>>> instead.
>>>
>>> Additional checks in VM make 0.5-1% slowdown in term of instruction 
>>> retired

>>> reported by callgrind.
>>
>> A single check would save those additional instructions and branches, 
>> and would actually improve things on Windows (since this PR doesn't 
>> change anything there).

>
> If you or Bob show me a better working solution (or just PoC), I'll be 
> only happy with this.


I looked at it; if we had an already existing if (EG(exception)) branch 
there, we could actually save something, but Dmitry put it just in jumping 
ops, where we never have an exception check. (And there we need a check as 
else a while(1) {} would never be timed out - i.e. when there are no ops 
inside which actually do a check_exception) … so this 
EG(something_unexpected_to_check) is even more expensive.


Yeah, when I was going to reply, I went to look again and saw that 
EG(exception) isn't explicitly checked nearly as often as I thought!


But despite it adding 0.5~1% more instructions, according to Dmitry, one can 
see in the Intel benchmark e-mails that it doesn't really hurt anything (at 
all).  That's expected, really.  The extra instructions, I believe, are 
independent, e.g. the variable can be loaded and tested ahead of time while 
just a few other instructions are doing work.  And the branch is perfectly 
predictable and never taken, which is as good as you can get...


Things would be easy if we could just alter the return addresses of the 
opcode handlers or similar magic, but I doubt that's a very nice 
cross-platform solution...


What were you thinking of?  That wouldn't work anyway with handlers that 
don't return (GOTO VM, etc.).  But, it doesn't really seem to be anything to 
worry about now with the benchmarks.



If you have an even better idea than I do… please show a PoC :-)

Thanks,
Bob


- Matt 



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

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

[Dmitry Stogov]

On 04/27/2016 08:25 AM, Pierrick Charron wrote:

Hi all,

First of all thanks dmitry for your great work and for bringing the 
RFC back to life.


I think it would be great to allow users to define their own 
annotations and give them some structure (what the annotation is made 
of). For example let's say I apply an annotation to define that a 
property is a string with a length. In the proposed RFC I will have 
something like this :


class Foo {
<>
public string $bar;
}

But how could i know for example that StringLength can take an extra 
parameters I would have to read the code of the annotation framework 
see how it parse, use it etc... But if I can define the structure 
(this is a quickly invented pseudo syntax and I'm not proposing it)


annotation MyAnnotation\StringLength {
private int $length;
private string $comment = "Default value";
}

With this definition I know that the Annotation take 2 parameters one 
int and one string, that the comment has a default value and can be 
omitted etc...


Also what I dislike about using a simple array with no definition is 
that you can't annotate an annotation since there is no definition. I 
know it can look complex but think about the power you can add to the 
system. It would help us solve some problems that could not be solved 
(or at least I can't see any way of doing it) if you can't have a 
definition you can't attach behaviour/metadata to it.


Here are some problems we could solve (those are just examples)

1. Are annotations inhereted or not ? Some will say yes, some now but 
I think they actually both make sense. For example we could imagine 
that if I annotate a method of my interface as deprecated I want it to 
be inhereted because all implementations are, but author annotation 
should not be inherited because I'm not necessarily the author of the 
implementation. So we could say that annotations are by default not 
inherited and we could have an <> annotation


<>
annotation deprecated {
}

annotation author {
public string $name;
public string $mail;
}

2. Is a specific kind of annotation applicable to only one kind of 
statement or multiple ? JIT don't make sense on a property...


<>
annotation jit {
}

3. Current version of the RFC propose that we could either have AST or 
to execute the AST but we could imagine to get both


annotation assert {
<>
public ast\node $node;
public string $message;
}

Again, this is just a couple of quick ideas, but this would make 
things less magic/obscure with a definition and far more flexible. If 
we agree that we want a definition we could work on how to create this 
definition (we could use some stuff from the old Annotations RFC 
https://wiki.php.net/rfc/annotations?rev=1302087566) to update this 
one with a new syntax or use interface as proposed in the first 
implementation


class Deprecated implements Annotation {
}

Maybe


didn't you think, that these annotation over-design made your RFC fail?

You can't create objects at compile-time, and should delay their 
creation until Reflection*::getAttributes().
Returning objects directly form Reflection*::getAttributes() doesn't 
improve flexibility at all.

This would just increase the complexity of the patch...

As I already said many times, all this extensions are possible to do in 
few PHP lines on top of base functionality.

See "Doctrine use-case" at https://wiki.php.net/rfc/attributes#use_cases

If you add these extensions directly into PHP implementation in C, 
you''ll have to support them, and you'll always miss some needs for 
"last use-case", but you won't able to change PHP behavior between major 
PHP versions.


Thanks. Dmitry.



Pierrick

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

[Anatol Belski]

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 ; 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 without any further logic. If there were a reduced 
patch with only such cases, it would be acceptable for 7.0 as well and there 
were probably no collisions expected. What do you think? 

Regards

Anatol


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