On 22 April 2016 at 11:39, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote:
>
> >
> >
> > On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:
> >
> > Hi Dmitry,
> >
> > As a previous suggester of metadata information built-
On 4/22/16 10:39 AM, guilhermebla...@gmail.com wrote:
On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote:
3- Did you put any thought on inheritance? What I mentioned in comment #1
is even smaller than what you implemented in RFC.
Assuming you keep the RFC approach, did you consider support
On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote:
>
>
> On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:
>
> Hi Dmitry,
>
> As a previous suggester of metadata information built-in into PHP, and
> also one of developers of the most used metadata library written in PHP, I
> understand
On Fri, 22 Apr 2016 07:12:13 +0300, Marcio Almada
wrote:
Hello everyone,
We just completed the draft for the "Callable Types" RFC. This RFC has
been
recently mentioned during other type related threads on this mailing
list,
so it feels to be the right time to put the proposal in context
Aaron Piotrowski wrote on 22/04/2016 15:56:
While this is somewhat off-topic of this particular RFC, since we can already
do general type-aliasing with `use`,
use SomeFoo as Foo;
perhaps similar syntax could be used for type expressions, eliminating the need
for a new keyword.
use callable(i
Levi Morrison wrote on 22/04/2016 15:39:
It would also allow for a general type-aliasing mechanism for single
names. This feature has been asked for in the past but I can't
remember the use-cases so this example is not very good:
One use I've seen is for making the "semantic type" of a scalar m
Hi!
> On Apr 22, 2016, at 9:39 AM, Levi Morrison wrote:
>
>> Not much else to say, the syntax reads a bit weird/heavy being all in-line
>> with the function signature but at the same time I can't imagine how else it
>> would work that would be any better.
>
> As mentioned on Reddit and in the f
On Apr 22, 2016 8:42 PM, "Ferenc Kovacs" wrote:
>
> co-RM can simply mean "one of the two RMs", and emphasize that somebody
> would volunteer to take the role but not being comfortable to doing it
> alone so I think we are on the same page.
Exactly. And I am convinced Davey and Anatol will come a
> Not much else to say, the syntax reads a bit weird/heavy being all in-line
> with the function signature but at the same time I can't imagine how else it
> would work that would be any better.
As mentioned on Reddit and in the future scope section of union types,
we may want to introduce named t
co-RM can simply mean "one of the two RMs", and emphasize that somebody
would volunteer to take the role but not being comfortable to doing it
alone so I think we are on the same page.
On Fri, Apr 22, 2016 at 2:50 PM, Julien Pauli wrote:
> On Fri, Apr 22, 2016 at 5:03 AM, Davey Shafik wrote:
>
On Fri, Apr 22, 2016 at 5:03 AM, Davey Shafik wrote:
> I'd interested in co-RMing 7.1 if someone else wants to step up also?
Hi.
The Co-RM is the version-1 RM, so it will be Anatol, RM of 7.0.
We are looking for a "master" RM here :-)
Julien.Pauli
--
PHP Internals - PHP Runtime Development M
Hi Dmitry!
> Hi,
>
>
> I would like to present an RFC proposing support for native annotation.
>
> The naming, syntax and behavior are mostly influenced by HHVM Hack, but not
> exactly the same.
>
> The most interesting difference is an ability to use arbitrary PHP
> expressions as attribute val
Results for project PHP master, build date 2016-04-22 06:28:58+03:00
commit: 304e5ae
previous commit:ecf6392
revision date: 2016-04-21 23:49:37+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
<> works fine
sapi/cli/php attr6.php
array(1) {
["Entity"]=>
bool(true)
}
$ cat attr6.php
>
function foo() {}
$r = new ReflectionFunction("foo");
var_dump($r->getAttributes());
?>
[dmitry@tpl2 CGI-DEBUG]$ sapi/cli/php attr6.php
array(1) {
["Entity"]=>
bool(true)
}
<> - doesn't work no
On 21/04/16 22:13, Dmitry Stogov wrote:
> I would like to present an RFC proposing support for native annotation.
I thought that the debate had been completed on annotation, and since
most of the work can be done in a stand alone extension, the various
parties were going to take that route and dev
On Thu, Apr 21, 2016 at 9:52 PM, Fleshgrinder wrote:
> On 4/21/2016 1:00 PM, Lin Yo-An wrote:
> > I think this is not to make PHP like Java, and it totally makes sense -
> > Nullable should be a type of a type instead of a state. In Haskell it's
> > named Maybe or Option, and It's better than Nul
On 22/04/2016 05:12, Marcio Almada wrote:
Hello everyone,
We just completed the draft for the "Callable Types" RFC. This RFC has been
recently mentioned during other type related threads on this mailing list,
so it feels to be the right time to put the proposal in context:
The proposal is at ht
On 22/04/2016 08:17, Dmitry Stogov wrote:
On 04/22/2016 05:15 AM, Sara Golemon wrote:
On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov wrote:
I would like to present an RFC proposing support for native annotation.
I'm trying to imagine where the benefit of non-constant expressions
comes in.
I'm having a crack at it now. Seeing if I can use it to plug a new
Annotation driver for Doctrine.
Couple of things I've found so far are:
<> with empty args doesn't work.
<> namespace doesn't work.
On the subject of using @, that could denote a class constructor, unless
someone already mention
On 04/22/2016 05:15 AM, Sara Golemon wrote:
On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov wrote:
I would like to present an RFC proposing support for native annotation.
I'm trying to imagine where the benefit of non-constant expressions comes in.
<>
Assuming we roll in php-ast at the sam
On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:
Hi Dmitry,
As a previous suggester of metadata information built-in into PHP, and
also one of developers of the most used metadata library written in
PHP, I understand this feature implementation requires several design
decisions and
21 matches
Mail list logo
