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. Genera
> > 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
> > > counter-intuit
> > 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 ar
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 de
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 choi
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 thr
On 19.03.2019 at 15:58, Nikita Popov wrote:
> I'm wondering if we shouldn't consider a new object oriented API for PCRE
> which can return a match object where subpattern positions and contents can
> be queried via method calls, so you only pay for the parts that you do
> access.
+1
--
Christoph
They sound like justifications for 5.6 support being extended.
I think there are good reasons to stick to schedule for 7.4: 8.0 is certain
to contain JIT, 7.4 is not, but should 7.4 get the JIT then it will be
experimental, and because of ABI guarantees and BC concerns will be more or
less stale i
Den 2019-03-19 kl. 17:53, skrev Sebastian Bergmann:
Am 19.03.2019 um 17:43 schrieb Joe Watkins:
At least I'd like someone to explain in detail why we should extend
support
for 7.4?
Seconded.
For us the extended support of 5.6 has been very beneficial.
Primarily for two reasons:
- A large le
On 18.03.2019 at 13:23, Kalle Sommer Nielsen wrote:
> Den man. 18. mar. 2019 kl. 07.56 skrev Sebastian Bergmann :
>
>> Am 17.03.2019 um 19:37 schrieb Derick Rethans:
>>
>>> Commit:6eb83a63e1833f0991af4c5533269c8af96c
>>> Author:Ignace Nyamagana Butera Tue, 26
>>> Feb 2019 21:
Am 19.03.2019 um 17:43 schrieb Joe Watkins:
At least I'd like someone to explain in detail why we should extend support
for 7.4?
Seconded.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm not so sure it's worth adopting as policy. It's.my understanding that
5.6 was extended for reasons that may not apply to the 7.4-8 upgrade. It's
likely less painful, it's likely better prepared with 7.4 raising
appropriate deprecation notices and such.
At least I'd like someone to explain in d
On Mon, Mar 18, 2019 at 2:43 PM Nikita Popov wrote:
> On Thu, Mar 14, 2019 at 8:33 PM C. Scott Ananian
> wrote:
>
>> 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 lex
On Tue, Mar 19, 2019 at 9:49 AM Remi Collet wrote:
> >> Yay! And on that topic, did we come to a consensus on whether or not
7.4
> > was going to have an extended support cycle the way 5.6 did? If so, how
> > long was it?
>
> 5.6 support, as latest 5.x, was extended by 1 year
>
> I think it make s
Le 18/03/2019 à 20:08, Sara Golemon a écrit :
>> Ladies and gentlemen, I give you your PHP 7.4 Release Managers:
>>
>> Peter Kokot and Derick Rethans
Congrats to Peter and Derick !
>>
>> Yay! And on that topic, did we come to a consensus on whether or not 7.4
> was going to have an extended sup
On Mo, 2019-03-18 at 23:30 +0100, David Zuelke wrote:
>
> It would be really useful for e.g. code check systems, tools like
> Composer, hosting platforms, to inform the user of an upcoming or
> past
> EOM/EOL date, without having to maintain a list of these dates
> separately (by copying from, or
On Tue, Mar 19, 2019 at 11:59 AM Pierre Joye wrote:
> On Tue, Mar 19, 2019, 3:29 PM Nikita Popov wrote:
>
> > On Mon, Mar 18, 2019 at 11:31 PM David Zuelke
> > wrote:
> >
> > > Hi all,
> > >
> > > Would it not be lovely to have, say, two new constants, that contain
> > > the date (ISO, UTC, I g
On Tue, Mar 19, 2019, 3:29 PM Nikita Popov wrote:
> On Mon, Mar 18, 2019 at 11:31 PM David Zuelke
> wrote:
>
> > Hi all,
> >
> > Would it not be lovely to have, say, two new constants, that contain
> > the date (ISO, UTC, I guess) of when the running PHP series will be
> > end-of-maintenance and
On 19.03.2019 at 11:30, Robert Hickman wrote:
> On Tue, 19 Mar 2019 at 00:55, Ben Ramsey wrote:
>
>> On Mar 18, 2019, at 18:45, Robert Hickman wrote:
>>
>> 1: I have seen an extension which allows functions/classes to be
>> redefined, although I can't remember what it is called.
>>
>> Maybe you’
On Tue, 19 Mar 2019 at 00:55, Ben Ramsey wrote:
>
>
> On Mar 18, 2019, at 18:45, Robert Hickman wrote:
>
>
> 1: I have seen an extension which allows functions/classes to be
> redefined, although I can't remember what it is called.
>
>
>
> Maybe you’re thinking of the runkit extension?
> https:/
On Mon, Mar 18, 2019 at 11:31 PM David Zuelke
wrote:
> Hi all,
>
> Would it not be lovely to have, say, two new constants, that contain
> the date (ISO, UTC, I guess) of when the running PHP series will be
> end-of-maintenance and end-of-life?
>
> Of course PHP_VERSION_SERIES_EOM_DATE and PHP_VER
22 matches
Mail list logo
