czw., 14 mar 2019, 04:22 użytkownik Larry Garfield
napisał:
> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote:
> > On 13/03/2019 21:10, Dik Takken wrote:
> > > So in practice, I expect that
> > > using comprehensions as proposed in the new RFC will also require doing
> > > a lot of iterator
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
On 13 March 2019 15:56:40 GMT+00:00, Nikita Popov wrote:
>Motivated by the recent list comprehensions RFC, I think it's time we
>took
>another look at short closures:
>
>https://wiki.php.net/rfc/arrow_functions_v2
Hi Nikita,
Thanks for reviving this. I think the RFC does a great job of
justifyin
Hi,
it's nice to see this going on again :)
while reading the rfc I was wondering, why do we need the "static" keyword,
couldn't static function be detected automatically ?
I guess this apply to the existing closure syntax as well so to get more on
this topic I'll share my preferences on th
This makes me thinking, has this syntax been considered?
($x) => { $x * $y }
Nested:
($x) => { ($y) => { $x * $y } }
AFAICS, we don't need the brackets around the whole expression, as this
should be parsable without any ambiguity; and the syntax would be closer to
that of JavaScript.
On Thu,
On Thu, 14 Mar 2019 at 14:12, Benjamin Morel
wrote:
> This makes me thinking, has this syntax been considered?
>
> ($x) => { $x * $y }
>
> Nested:
>
> ($x) => { ($y) => { $x * $y } }
>
Wouldn't this have all the same parser problems as the RFC discusses?
The problem, as I understand it, is not
>
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
> lookahead.
You're right, I was only thinking about resolving the ambiguity with array
keys. It's too bad if the parser implementation considerations take
precedence over the purity of the language, but I can understan
Any update on this? One commonly requested feature on the downloads
page can be implemented once the mirrors are gone, which is to
directly link to to the file (instead of a Choose a Mirror page).
On Wed, Feb 27, 2019 at 9:28 AM Derick Rethans wrote:
>
> Hi!
>
> The PHP.net website has in the las
Em qui, 14 de mar de 2019 às 03:17, Rowan Collins
escreveu:
> I don't think this helps, because you can put brackets around any
> expression, for precedence, and any expression can appear on the left of an
> array literal:
>
> $foo = [ ($bar + 1) * 2 => $baz ];
>
> So the following, while redunda
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
On Thu, 14 Mar 2019 at 15:10, Benjamin Morel
wrote:
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
>> lookahead.
>
>
> You're right, I was only thinking about resolving the ambiguity with array
> keys. It's too bad if the parser implementation considerations take
> pr
On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins wrote:
>
> Is it really that important to save two key strokes per closure?
>
I'd say that the (probably overwhelming) majority of arrow functions
have a single parameter and, in those cases, the JS syntax saves four
characters, ignoring whitespace. A
On Thu, 14 Mar 2019 at 18:20, Josh Di Fabio wrote:
> On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins
> wrote:
> >
> > Is it really that important to save two key strokes per closure?
> >
>
> I'd say that the (probably overwhelming) majority of arrow functions
> have a single parameter and, in thos
Hello,
A timeline would be nice and information on if locally mirroring it (on an
internal hostname) will still be possible.
Also it would be nice to know if you will be contacting the rsync mirror
maintainers and what you want to do with them.
I've said before and I will repeat again: let me
I'm floating an idea for an RFC here.
I'm working on the wikimedia/remex-html library for high-performance
PHP-native HTML5 parsing. When creating a high-performance lexer, it is
worthwhile to try to reduce the number of string copies made. You can
generally perform matches using offsets into yo
I note that there was some recent discussion about fixing DOMNameSpaceNode
on this list. I'd like to bring up a (perhaps) related issue: the
dom_reconcile_ns() function which is called whenever a new namespaced node
(for example, created with Document#createElementNS) is inserted into the
tree. d
On Thu, March 14, 2019 10:41 AM Nikita Popov wrote:
> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>
> > Hi internals,
> >
> > Motivated by the recent list comprehensions RFC, I think it's time we took
> > another look at short closures:
> >
> > https://wiki.php.net/rfc/arrow_functions_v
Hi,
The plan is to start rolling this out somewhere in the next two weeks,
pending solving the problem of not 404ing the xx.php.net URLs. What I
would like to do is, to 301 redirect these to the canonical URLs so that
search indexes etc can get updated over time. But, I don't quite know
where
On 14-03-19 04:21, Larry Garfield wrote:
> To the question of having both a generator and array version, I would have to
> say no. As noted in the RFC, most cases where you'd want to use a
> comprehension are not places where you'd be feeding the result into an array
> function. On the off cha
On 13-03-19 23:30, Rowan Collins wrote:
> At risk of complicating things further, might the solution to that be to
> have a shorter syntax for iterator_to_array in general?
>
> It's a shame array-casts are defined for arbitrary objects, else we
> could have (array)$iterator - and therefore (array)
On Thu, Mar 14, 2019, at 3:41 PM, Theodore Brown wrote:
> > As a small update, I've implemented a proof of concept that uses the ($x)
> > ==> $x * $multiplier syntax (or $x ==> $x * $multiplier for short) in
> > https://github.com/php/php-src/pull/3945. As mentioned in the RFC, this
> > requires s
Hey all,
I'm looking to get feedback on a RFC I want to propose.
PHP RFC: Addition of the 'struct' data type.
Introduction:
PHP has many data types, but does not offer something that is the
equivalent to the C struct data type.
The purpose of this RFC is to propose a data type of 'struct', w
22 matches
Mail list logo
