Hi!
> It's also possible to write:
>
> < "id" = "system_branding_block",
> "admin_label" = @Translation("Site branding")
> ]))>>
>
>
> you don't need to split your annotation into many attributes. You should
> just adopt its syntax to become a valid PHP expression.
> This expression
On 05/01/2016 10:47 PM, Larry Garfield wrote:
On 04/30/2016 06:21 PM, Rowan Collins wrote:
On 30/04/2016 23:45, Stanislav Malyshev wrote:
Oh, of course you can have methods, but then it is strange conceptually
- you have a normal class, which some other part of the language just
uses for some
On 04/30/2016 02:47 AM, Larry Garfield wrote:
Most of the examples that have been given so far are either trivial
boolean flags or data validation rules to be evaled. In practice,
very little of Drupal's use of annotations in Drupal 8 fit either
category. Rather, they're used primarily as,
Am 03.05.2016 um 23:36 schrieb Anatol Belski:
> Congrats and godspeed, guys!
Hear, hear!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey all,
As Joe said, thanks for voting, and we have lots of work ahead of us to
make sure that 7.1 is a solid release — I'll do my best to ensure that
happens!
- Davey
On Tue, May 3, 2016 at 10:01 PM, Joe Watkins wrote:
> Morning internals,
>
> Thanks for voting :)
>
> Let the work co
> I don't think we should wait, I was just thinking that it might not be ready
> until that time.
>
> Also, if we plan on rewriting streams and I/O to all be async and use libuv
> underneath, that would probably be a BC break unless the existing functions
> just become blocking interfaces for a sep
On 05/04/2016 11:44 AM, Niklas Keller wrote:
2016-05-04 16:40 GMT+02:00 Stephen Coakley :
Why do we have to wait until PHP 8? Should be mostly backwards compatible
and be fine in 7.2 or so. Issue is probably more deciding on an API.
I don't think we should wait, I was just thinking that it mig
>> /Legend speaks of such plans, but they come and go in whispers. Like a
>> shadow, or a mist from the east. The prophecy spake of such features
>> targeting PHP8; lo, most believe it to be myth./
>
>
> Why do we have to wait until PHP 8? Should be mostly backwards compatible
> and be fine in 7.2
2016-05-04 16:40 GMT+02:00 Stephen Coakley :
> On 05/04/2016 05:59 AM, S.A.N wrote:
>
>> EventLoop interface, on development stage:
>> https://github.com/async-interop/event-loop
>>
>
> That's a userland design for event loops; async/await and coroutines don't
> necessarily depend on an event loop
Hi everyone,
You may recall that PHP 7.0 introduced a new API for processing
arguments to internal functions, the "Fast Parameter Parsing API" or
FAST_ZPP (https://wiki.php.net/rfc/fast_zpp), which is an alternative to
the existing zend_parse_parameters function family.
Since FAST_ZPP was im
Results for project PHP master, build date 2016-05-04 11:14:20+03:00
commit: ee55110
previous commit:153b27d
revision date: 2016-05-03 19:11:15+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 05/04/2016 05:59 AM, S.A.N wrote:
EventLoop interface, on development stage:
https://github.com/async-interop/event-loop
That's a userland design for event loops; async/await and coroutines
don't necessarily depend on an event loop. They could be added to the
language without an event loop
On 4 May 2016 10:41 pm, "Rowan Collins" wrote:
>
>
> You could either think of this as "setting lots of variables":
>
> new Foo { $bar = 1, $baz = 2 }
>
> or you could think of it as "an object literal like an array literal":
>
> new Foo { 'bar' => 1, 'baz' => 2 }
>
I think a $ is only necessary
Jesse Schalken wrote on 04/05/2016 13:20:
(maybe there should be a $ before the property names, not sure)
And there's the rub! :P
When named parameters have been discussed before, there was a lot of
bikeshedding over what the syntax should look like, and this is arguably
a very similar featu
On Sat, Apr 30, 2016 at 9:47 AM, Larry Garfield
wrote:
> 3) Some way to provide a data definition for the annotation that can be
> checked at compile time. This could be classes, a la Doctrine. It could be
> a new Annotation type as others have suggested. It could be something
> else, akin to a
> I think we can spoonfeed the massive undertaking a bit by spreading it
> across several iterations just to get things going. An idea I had was to
> just begin by providing coroutines as part of the language. That would
> include a `\Coroutine` class, as well as await / async keywords. This would
On Wed, 4 May 2016, Dmitry Stogov wrote:
> I don't see a big problem exporting zif_pass, if this's really necessary.
Bob already committed that, and I've a PR for Xdebug too:
https://github.com/xdebug/xdebug/pull/271/commits/c4a539d75f0d2546e9d0cb0dbc06f5a7a31f447e
cheers,
Derick
>
On Sun, May 1, 2016 at 4:05 AM, Larry Garfield
wrote:
>
> In a way... Sara, this syntax feels like it's only one step removed from
> promises; if any of the chained steps involve IO, it becomes basically what
> promises are for. Am I barking down the wrong tree, or is there something
> we could
Morning Dmitry,
Bob already exported it.
http://git.php.net/?p=php-src.git;a=commit;h=f59de7ea368da55f1f21ca82810febb3cdec06f0
Cheers
Joe
On Wed, May 4, 2016 at 7:28 AM, Dmitry Stogov wrote:
> I don't see a big problem exporting zif_pass, if this's really necessary.
>
>
> Thanks. Dmitry.
Hi Fleshgrinder
On Fri, Apr 29, 2016 at 4:42 AM, Fleshgrinder wrote:
> Is there a reason why you think that Design by Contract (DbC) should be
> implemented via annotations/attributes?
It's not complement of DbC, although it could be used.
Basic DbC idea is "Do validations always and fully duri
20 matches
Mail list logo
