On Tue, Apr 9, 2019, at 3:31 AM, Stephen Reay wrote:
>
>
> > On 5 Apr 2019, at 21:29, Larry Garfield wrote:
> >
> > On Thu, Apr 4, 2019, at 10:46 PM, Stephen Reay wrote:
> >
> >>> Discussion:
> >>>
> >>> For me, the inability to work with arrays is the big problem with the
> >>> second
> On 5 Apr 2019, at 21:29, Larry Garfield wrote:
>
> On Thu, Apr 4, 2019, at 10:46 PM, Stephen Reay wrote:
>
>>> Discussion:
>>>
>>> For me, the inability to work with arrays is the big problem with the
>>> second approach. I very very often am type declaring my returns and
>>>
On Thu, Apr 4, 2019, at 10:46 PM, Stephen Reay wrote:
> > Discussion:
> >
> > For me, the inability to work with arrays is the big problem with the
> > second approach. I very very often am type declaring my returns and
> > parameters as `iterable`, which means I may have an array and not
Hi Larry,
pt., 5 kwi 2019 o 03:55 Larry Garfield napisał(a):
>
> Advantages:
>
> * Very compact.
> * Works for both arrays and traversables
> * Would play very nicely with the proposed spread operator for iterables (
> https://wiki.php.net/rfc/spread_operator_for_array).
>
IMO not nicely cause
> On 5 Apr 2019, at 08:54, Larry Garfield wrote:
>
> On Wed, Mar 13, 2019, at 10:22 PM, Larry Garfield wrote:
>> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote:
>>> On 13/03/2019 21:10, Dik Takken wrote:
>
>> If I can summarize the responses so far, they seem to fall into one of
>>
On Wed, Mar 13, 2019, at 10:22 PM, Larry Garfield wrote:
> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote:
> > On 13/03/2019 21:10, Dik Takken wrote:
> If I can summarize the responses so far, they seem to fall into one of
> two categories:
>
> 1) Love the idea, but wouldn't
On 21-03-19 16:22, Larry Garfield wrote:
> OTOH, if we just have the one syntax:
>
> [foreach $foo as $bar yield $bar*2] // gives a generator
>
> And include a nicer "fast-forward" operator than interator_to_array(), then
> we automatically get:
>
> ...[foreach $foo as $bar yield $bar*2] //
On Thu, 21 Mar 2019 at 16:15, Rowan Collins wrote:
>
> On Thu, 21 Mar 2019 at 15:21, Robert Hickman wrote:
>>
>> In this case nextIf() would have to be implemented something like:
>>
>> function nextif($someCondition) {
>> foreach($this->iteratorValue as $x) {
>> if(>
On Thu, 21 Mar 2019 at 15:21, Robert Hickman wrote:
> In this case nextIf() would have to be implemented something like:
>
> function nextif($someCondition) {
> foreach($this->iteratorValue as $x) {
> if( yield $x;
> }
> }
> }
>
> iterator_to_array would need
On Wed, Mar 20, 2019, at 5:44 PM, Rowan Collins wrote:
> On 20/03/2019 20:39, Stanislav Malyshev wrote:
> > Hi!
> >
> >> It's not that you can't make an array into a generator, but you can't make
> >> an eagerly-evaluated expression into a lazily-evaluated one.
> > Not sure what you mean here.
>
> But $filteredArrayIterator->next() is actually $arrayIterator->next() with
> a built-in if check, so you could also picture it as doing this:
>
> while ( $element = $arrayIterator->nextIf ( someCondition ) ) {
> $newArray[] = $element;
> }
>
In this case nextIf() would have to be
On Thu, 21 Mar 2019 at 11:00, Robert Hickman wrote:
> I was only making a point for where a non-generator version of
> comprehensions could be useful, under the premise "Therefore, a
> lazy-evaluating syntax is more powerful, in that it can do everything
> an eager-evaluating one can do *and
I was only making a point for where a non-generator version of
comprehensions could be useful, under the premise "Therefore, a
lazy-evaluating syntax is more powerful, in that it can do everything
an eager-evaluating one can do *and more*.". This implies that it
dosn't have any downsides, whereas
On 21 March 2019 00:39:20 GMT+00:00, Robert Hickman
wrote:
>For my use case of PHP, get some content from a DB and dump it into a
>template, I don't see much benefit to generators.
With respect, so what? I never said that every use case benefits from
generators, nor are we discussing whether
> > Hi!
> >
> >> It's not that you can't make an array into a generator, but you can't make
> >> an eagerly-evaluated expression into a lazily-evaluated one.
> > Not sure what you mean here.
>
>
> I mean that, given a syntax that lazily-evaluates something, you can
> "fast-forward" the result to
On 20/03/2019 20:39, Stanislav Malyshev wrote:
Hi!
It's not that you can't make an array into a generator, but you can't make
an eagerly-evaluated expression into a lazily-evaluated one.
Not sure what you mean here.
I mean that, given a syntax that lazily-evaluates something, you can
Hi!
> It's not that you can't make an array into a generator, but you can't make
> an eagerly-evaluated expression into a lazily-evaluated one.
Not sure what you mean here. If you already have the data, of course you
can't un-evaluate it in order to lazily-evaluate it again. But why would
you,
On Tue, Mar 19, 2019, at 3:25 PM, Levi Morrison wrote:
> Today in the Dart world, Bob Nystrom published an article called
> [Making Dart a Better Language for UI][1]. I think it's an incredibly
> relevant article, since it is essentially about comprehensions, why
> they are a thing, as well as
On Wed, 20 Mar 2019 at 00:35, Stanislav Malyshev
wrote:
> > And converting from a generator to an array is trivial; the other
> > way, very not so much.
>
> BTW, how it's not trivial to make generator from array?
>
> function generate($array) { foreach($array as $k => $v) yield $k => $v; }
>
>
>> Honestly, I cannot think of any case where I'd use a comprehension
>> where I would definitely want an array and not a generator. In the
>> majority case both work equally well, cool, but I don't know when I
>> would even use an array-dependent version.
>> And converting from a generator to an
Hi!
> Honestly, I cannot think of any case where I'd use a comprehension
> where I would definitely want an array and not a generator. In the
> majority case both work equally well, cool, but I don't know when I
> would even use an array-dependent version.
They wouldn't work equally well.
> > In python comprehensions on [] makes a list and comprehensions in {}
> > make a dictionary (list and dict comprehensions). As PHP only has one
> > 'array' type using [] makes sense. Along that train of thought, should
> > comprehensions also be possible in the old array() syntax?
>
> Honestly,
On Tue, Mar 19, 2019, at 7:10 PM, Robert Hickman wrote:
> > > Why not apply the same approach to PHP? There is iterator_to_array() to
> > > convert a generator to an array, so we may not need both syntaxes.
> > > However, I think using [] for something that is *not an array* is
> > >
> > Why not apply the same approach to PHP? There is iterator_to_array() to
> > convert a generator to an array, so we may not need both syntaxes.
> > However, I think using [] for something that is *not an array* is
> > counter-intuitive.
>
> No, I would definitely be for []-syntax producing an
Hi!
> In Python, the difference is that []-syntax gives you a list
> (pre-comupted), whereas without the [] you get a generator
> (generate-on-demand). This distinction is important because the
> generator might be iterating over something non-repeatable (e.g. another
> generator), or have some
On 19/03/2019 20:24, Levi Morrison wrote:
Today in the Dart world, Bob Nystrom published an article called
[Making Dart a Better Language for UI][1]. I think it's an incredibly
relevant article, since it is essentially about comprehensions, why
they are a thing, as well as some of the design
Today in the Dart world, Bob Nystrom published an article called
[Making Dart a Better Language for UI][1]. I think it's an incredibly
relevant article, since it is essentially about comprehensions, why
they are a thing, as well as some of the design choices they made.
I think everyone in this
Hi,
Stanislav Malyshev wrote:
Finally, Python makes a distinction between list comprehensions using []
and generator expressions using (). This proposal effectively corresponds
to generator expressions, but uses the [] syntax. I'm wondering if that
will cause confusion.
Do we need this
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
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
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
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_to_array(). A dual comprehension syntax could fix that.
>
>
> At
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_to_array(). A dual comprehension syntax could fix that.
At risk of complicating things further, might the solution to that be to
have
Hi
Den tir. 12. mar. 2019 kl. 18.36 skrev Chase Peeler :
> I've never liked "developers might use it wrong" as reason to not implement
> something, especially if hard to read/complex code is the worst impact to
> improper use.
Me neither to be fair, but I think it is a fair consideration to
On 11-03-19 05:29, Larry Garfield wrote:
> Sara and I tried putting the expression first, as in Python, but that made
> the lexer very unhappy
There is another possible reason to put the expression last: It
preserves the ordering of the intended foreach loop. What I mean to say
is this: One can
Hi!
> I think my main point of feedback would be to stick closer to existing PHP
> syntax, even if it costs us some brevity. I would prefer
>
> $gen = [foreach ($list as $x) if ($x % 2) yield $x * 2];
>
> over
>
> $gen = [for $list as $x if $x % 2 yield $x * 2];
Agree here. There's a
On Tue, Mar 12, 2019 at 10:12 AM Kalle Sommer Nielsen wrote:
> Hi
>
> Den tir. 12. mar. 2019 kl. 15.49 skrev Chase Peeler >:
> > Everything looks weird and "non-phpish" when it's new. OO constructs
> weren't PHP-ish at first, because PHP didn't originally support OO. Imagine
> "foreach" didn't
On Sun, Mar 10, 2019 at 3:45 PM Larry Garfield wrote:
>
> Hello, peoples. I know it's been discussed once or twice before on the list,
> many years ago, but not recently. I therefore feel OK putting forth the
> following draft proposal for Comprehensions, aka "compact generators", in PHP:
>
>
Hi,
the real fun starts when people start to put list comprehension in a
list comprehension in a list comprehension. And the result is one-liners
that are pretty dense and write once never read.
The problem during software development are not the key strokes, it's
the time which later has to
Den 2019-03-11 kl. 13:16, skrev Nikita Popov:
On Sun, Mar 10, 2019 at 10:45 PM Larry Garfield
wrote:
Hello, peoples. I know it's been discussed once or twice before on the
list, many years ago, but not recently. I therefore feel OK putting forth
the following draft proposal for
On Sun, Mar 10, 2019 at 4:45 PM Larry Garfield
wrote:
> Sara Golemon has written a preliminary patch that is partially complete
> (see the RFC link for details, it's impressively simple), but unfortunately
> doesn't have the bandwidth to complete it at this time. I am therefore
> looking for
Hi
Den tir. 12. mar. 2019 kl. 15.49 skrev Chase Peeler :
> Everything looks weird and "non-phpish" when it's new. OO constructs weren't
> PHP-ish at first, because PHP didn't originally support OO. Imagine "foreach"
> didn't exist in PHP and we were still using while(list($key,$value) =
>
On Tue, Mar 12, 2019 at 4:55 AM Kalle Sommer Nielsen wrote:
> Hi
>
> Den søn. 10. mar. 2019 kl. 23.45 skrev Larry Garfield <
> la...@garfieldtech.com>:
> >
> > Hello, peoples. I know it's been discussed once or twice before on the
> list, many years ago, but not recently. I therefore feel OK
Hi
Den søn. 10. mar. 2019 kl. 23.45 skrev Larry Garfield :
>
> Hello, peoples. I know it's been discussed once or twice before on the list,
> many years ago, but not recently. I therefore feel OK putting forth the
> following draft proposal for Comprehensions, aka "compact generators", in
On Mon, Mar 11, 2019, at 8:16 AM, Nikita Popov wrote:
> On Sun, Mar 10, 2019 at 10:45 PM Larry Garfield
> wrote:
>
> > Hello, peoples. I know it's been discussed once or twice before on the
> > list, many years ago, but not recently. I therefore feel OK putting forth
> > the following draft
On Sun, Mar 10, 2019 at 10:45 PM Larry Garfield
wrote:
> Hello, peoples. I know it's been discussed once or twice before on the
> list, many years ago, but not recently. I therefore feel OK putting forth
> the following draft proposal for Comprehensions, aka "compact generators",
> in PHP:
>
>
On Sun, Mar 10, 2019, at 7:16 PM, Bob Weinand wrote:
> > Am 10.03.2019 um 22:44 schrieb Larry Garfield :
> >
> > Hello, peoples. I know it's been discussed once or twice before on the
> > list, many years ago, but not recently. I therefore feel OK putting forth
> > the following draft
Hi Larry,
I'm still digesting the syntax and people have already said about it the
most important things.
I mostly wanted to mention that I think comprehensions should return
\Iterator instead of \Generator. There is nothing that stopped us from
having lazy iterators, even before generators were
On Sun, 10 Mar 2019 at 22:45, Larry Garfield wrote:
> Hello, peoples. I know it's been discussed once or twice before on the
> list, many years ago, but not recently. I therefore feel OK putting forth
> the following draft proposal for Comprehensions, aka "compact generators",
> in PHP:
>
>
> Am 10.03.2019 um 22:44 schrieb Larry Garfield :
>
> Hello, peoples. I know it's been discussed once or twice before on the list,
> many years ago, but not recently. I therefore feel OK putting forth the
> following draft proposal for Comprehensions, aka "compact generators", in PHP:
>
>
Hi!
proposed syntax:
> $gen = [for $list as $x if $x % 2 yield $x*2];
>
current php + short closures:
$gen = () => foreach($list as $x) if($x % 2) yield $x * 2;
1- parentheses could be optional around control structures, so `if(true){}`
could be simply `if true{}`
2- "for" could accept the
> array_map and array_filter combined
This example has array_map and array_filter in wrong order (duplicated once
or twice below as well).
The RFC proposes to allow multiple `for`s in comprehensions, and really
could benefit from an example of such usage.
52 matches
Mail list logo
