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 Malyshe
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/ph
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 &
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 fun
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 tha
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 dis
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 pro
> 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, u
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...@gmai
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*
>
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 bl
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
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
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
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
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 a
> -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 c
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-
>
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
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
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 key
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
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,
>
> > ---
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 the
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
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 2
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
27 matches
Mail list logo
