On Tue, Jul 10, 2018 at 10:58 PM, Alice Wonder wrote:
> Using github may not be the most reliable method.
>
> Look at what is most popularly used in composer dependencies.
Absolutely - but it's the first one that came to mind when thinking of "how
to get popular repositories really quick".
On Tue, Jul 10, 2018 at 7:58 PM, Alice Wonder wrote:
> On 07/10/2018 07:20 PM, Ryan wrote:
>
>> On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker wrote:
>>
>>
>>> That is a matter of style, as I find $a = func() or die more clear that
>>> the version that uses ||
>>>
>>> Not chaining stuff
On 07/10/2018 07:20 PM, Ryan wrote:
On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker wrote:
That is a matter of style, as I find $a = func() or die more clear that
the version that uses ||
Not chaining stuff together is a third style.
This feels like a Python PEP request. By that I mean that
On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker wrote:
>
> That is a matter of style, as I find $a = func() or die more clear that
> the version that uses ||
>
> Not chaining stuff together is a third style.
>
> This feels like a Python PEP request. By that I mean that Python wants to
> have only
(Sorry for the duplicate message there, got some hotkeys wrong in my client).
Here's the implementation:
https://github.com/php/php-src/compare/master...morrisonlevi:array_first-and-array_last
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, Jul 10, 2018 at 6:41 PM Levi Morrison wrote:
>
> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote:
> >
> > On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote:
> >
> > > I don't think we have an agreement on dealing with non-existing value, and
> > > the way this RFC proposed, just
On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote:
>
> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote:
>
> > I don't think we have an agreement on dealing with non-existing value, and
> > the way this RFC proposed, just returning null without any notice/warning,
> > is wrong IMO. I know
On 10/07/2018 20:38, Michael Morris wrote:
While having these behave they do is unfortunate, it is hardly the only one
of PHP's quirks. Ever looked at the ramifications of loose typing with
comparison?http://phpsadness.com/sad/52
Eugh, I hate that site, and I hate that it's so widely linked
Hi,
> -Original Message-
> From: Stanislav Malyshev
> Sent: Tuesday, July 10, 2018 8:55 PM
> To: Sara Golemon ; PHP internals
> Subject: Re: [PHP-DEV] On not rushing things at the last minute
>
> Hi!
>
> > I'm disappointed by the last minute kitchen-sink dump of RFCs being
> > raised,
Hi!
> the wall. By deciding not to include this in PHP 7.3, we are essentially
> making an implicit decision that PHP 7.4 is going to be a relatively
> ordinary feature release rather than a deprecation-only one. (Which is fine
> by me really, I don't like the idea of a release that's all stick
On Mon, Jul 9, 2018 at 10:03 PM Ryan wrote:
> Hello all! Longtime PHP user, first-time contributor to internals (sorry
> if I screw anything up)!
>
> I'd like to propose either the deprecation (7.next - likely 7.4 at this
> point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and),
On 10/07/2018 20:11, Kalle Sommer Nielsen wrote:
Den tir. 10. jul. 2018 kl. 21.08 skrev David Rodrigues :
I think that "or" could be removed if PHP could supports inline conditionals
like:
die() if !$connected;
throw Exception() if fail();
$x = $y if (z() && w());
Or "when": die() when
On Tuesday, July 10, 2018 6:56:24 AM CDT Zeev Suraski wrote:
> On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalhães wrote:
> > On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote:
> >> I've also given several examples - some of them arguably quite bigger
> >> than
> >> this proposal - where we sat on
Den tir. 10. jul. 2018 kl. 21.08 skrev David Rodrigues :
>
> I think that "or" could be removed if PHP could supports inline conditionals
> like:
>
> die() if !$connected;
> throw Exception() if fail();
> $x = $y if (z() && w());
>
> Or "when": die() when !$connected;
>
> It seems more clear than
On 10/07/2018 14:10, Sara Golemon wrote:
What are the causes?
I have noticed three approximate (and overlapping) categories of late RFC:
1) Submarine features: Features which have been developed over a long
period, but where the author wanted to get things polished before
formally
I think that "or" could be removed if PHP could supports inline
conditionals like:
die() if !$connected;
throw Exception() if fail();
$x = $y if (z() && w());
Or "when": die() when !$connected;
It seems more clear than $connected or die().
Em ter, 10 de jul de 2018 às 15:59, Andrey Andreev
Hi,
On Tue, Jul 10, 2018 at 9:37 PM, Kalle Sommer Nielsen wrote:
> Den tir. 10. jul. 2018 kl. 20.22 skrev Larry Garfield
> :
>> "do() or die()" code is/was very common in example code, tutorials, and other
>> intro material because it means you don't need to think about error handling.
>
> I
On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote:
> I don't think we have an agreement on dealing with non-existing value, and
> the way this RFC proposed, just returning null without any notice/warning,
> is wrong IMO. I know we already do this in other array_* functions, but we
> cannot keep
Hi!
> I'm disappointed by the last minute kitchen-sink dump of RFCs being
> raised, rushed through discussion, and voted on with minimal periods.
> While I'm all for delivering useful features to end users, I don't
> want us to get in the habit of seeing months of quiet followed by
> weeks of
Den tir. 10. jul. 2018 kl. 20.22 skrev Larry Garfield :
> "do() or die()" code is/was very common in example code, tutorials, and other
> intro material because it means you don't need to think about error handling.
I personally wanted to extend this syntax but I never got around to it
to
On Tuesday, July 10, 2018 6:09:22 AM CDT Christoph M. Becker wrote:
> On 10.07.2018 at 11:01, Rowan Collins wrote:
> > While I've not seen it used much in PHP code, the "do this or die" idiom
> > is
> > common in Perl (which also has post-fix "if" and "unless" modifiers, so
> > those are a
> Hi Nikita,
>
> I'm a terrible person for only bringing this up now (I apologise for not
> following the list as closely as I used to), but one reason
> case-insensitive constants are maybe useful is they leave open the
> possibility of being able to access functions as values in future: like
>
I put that item onto the list.
The author of https://github.com/mikey179/bovigo-assert originally had
the issue that a function named `assert` behaves really weird.
`assert()` in namespaced code might refer to the namespaced `assert()`
function, but might also fall back to the global `assert()`.
Hi,
On Tue, Jul 10, 2018 at 4:10 PM, Sara Golemon wrote:
> I'm disappointed by the last minute kitchen-sink dump of RFCs being
> raised, rushed through discussion, and voted on with minimal periods.
> While I'm all for delivering useful features to end users, I don't
> want us to get in the
Den tir. 10. jul. 2018 kl. 17.26 skrev Dustin Wheeler :
> I'm relatively new to all of this. I think it's a bit strange to
> earmark a minor release as deprecation-only, but I also wasn't around
> for the last major upgrade to see discussion (was 5.6 the focus of
> many deprecations?)
Afair then
On Tue, Jul 10, 2018 at 1:43 PM Sara Golemon wrote:
>
> On Tue, Jul 10, 2018 at 9:26 AM, Dustin Wheeler wrote:
> > That said, if feature freeze for a release is announced well in
> > advance, published,
> >
> Depends on what you consider a proper announcement[1], but it is
> published[2] and the
Also voting no, and wished I had mailed earlier.
Accessing the keys and values separately is not a good design in my
opinion, as it leads to:
> All four functions either return the requested key/value
> or null if an empty array is provided.
Having what looks likes valid values returned for
Hi everyone,
I had a chat with Levi yesterday about the operator overloading side of
this RFC, and I'd like to try explain it as clearly as I can so that there
is no confusion.
Using <=> spaceship operator as an example, the operator is like a pointer
that references the internal
Thanks for explaining your vote Marco.
I realise it's probably too late but I'd like to respond anyway.
1. I was hoping that this proposal would reduce those edge cases and make
`==` on objects something useful.
2. That's true, but there are so many gotchas with the current behaviour
that I
On 7/10/2018 6:10 AM, Sara Golemon wrote:
I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of
On 09.07.2018 at 11:41, Derick Rethans wrote:
> On Wed, 4 Jul 2018, Christoph M. Becker wrote:
>
>> On 04.07.2018 at 12:24, Nikita Popov wrote:
>>
>>> On Wed, Jul 4, 2018 at 11:32 AM, Christoph M. Becker
>>> wrote:
>>>
On 04.07.2018 at 01:16, Jan Ehrhardt wrote:
> Another one:
On 10 July 2018 at 15:26, Dustin Wheeler wrote:
*snip*
> Personally (for Class Friendship), I opted to target either 7.4 or 8.0
> (whichever was decided to be next-in-line)
>
Seems to me this is one of the issues - that this is something that isn't
just set in stone. If there was an overall
On Tue, Jul 10, 2018 at 9:26 AM, Dustin Wheeler wrote:
> That said, if feature freeze for a release is announced well in
> advance, published,
>
Depends on what you consider a proper announcement[1], but it is
published[2] and the date can reliably be expected to occur around
mid-July until and
"Christoph M. Becker" in php.internals (Tue, 10 Jul 2018 12:04:10
+0200):
>Have you tried to convert the first two arguments via mbfl_no2encoding()[1]?
It compiles, but segfaults in 1 test on this line
https://github.com/php/pecl-mail-mailparse/blob/master/mailparse.c#L1466
Unhandled exception
>
> We don't need to solve this now, this week, because there are plenty
> of rushed, last-minute proposals on the table already. But I'd like
> folks to start thinking about this and ways we can mitigate this
> problem come future releases.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime
I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year
On Tue, Jul 10, 2018 at 12:35 PM, Christoph M. Becker
wrote:
> On 10.07.2018 at 09:36, Nikita Popov wrote:
>
> > To make sure there are no unreasonable expectations involved in this
> > decision: If this feature will not go into PHP 7.3, then it will in all
> > likelihood go into PHP 7.4
Le mar. 10 juil. 2018 à 14:56, Zeev Suraski a écrit :
> On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalhães wrote:
>
>> On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote:
>>
>>> I've also given several examples - some of them arguably quite bigger
>>> than
>>> this proposal - where we sat on
On 10.07.2018 at 13:41, Rowan Collins wrote:
> On 10 July 2018 at 12:09, Christoph M. Becker wrote:
>
>> “xor” is equivalent to ^ (sans the precedence).
>
> No, that's a *bitwise* XOR, which is a completely different operation:
>
> var_dump(1 xor 2); // bool(false)
> var_dump(1 ^ 2); //
On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalhães wrote:
> On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote:
>
>> I've also given several examples - some of them arguably quite bigger than
>> this proposal - where we sat on code for a very long time (multiple years
>> even) in order for it to
On 10 July 2018 at 12:09, Christoph M. Becker wrote:
>
> “xor” is equivalent to ^ (sans the precedence).
>
No, that's a *bitwise* XOR, which is a completely different operation:
var_dump(1 xor 2); // bool(false)
var_dump(1 ^ 2); // int(3)
A consistent logical XOR with the same precedence as
On 10.07.2018 at 11:01, Rowan Collins wrote:
> While I've not seen it used much in PHP code, the "do this or die" idiom is
> common in Perl (which also has post-fix "if" and "unless" modifiers, so
> those are a different feature again).
It seems to me the “do this or die” idiom at least has been
On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote:
> I've also given several examples - some of them arguably quite bigger than
> this proposal - where we sat on code for a very long time (multiple years
> even) in order for it to be included in a major version, and not a minor
> one (phpng,
On 10.07.2018 at 09:36, Nikita Popov wrote:
> To make sure there are no unreasonable expectations involved in this
> decision: If this feature will not go into PHP 7.3, then it will in all
> likelihood go into PHP 7.4 instead. I think I can safely say not just on
> behalf on Bob and myself, but
On Tue, Jul 10, 2018 at 1:22 PM Nicolas Grekas
wrote:
> 2018-07-10 11:18 GMT+02:00 Marco Pivetta :
>
> > It's been a few weeks since this has first landed here, and we're just
> > wasting time in relatively silly discussions at this point:
> >
> > - As I said earlier, this patch has already
On Tue, Jul 10, 2018 at 12:15 PM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> If we're seeking for a benefit, it would be by turning this to a
>>> ReflectionZval insteaf of ReflectionReference. There would be isRef, but
>>> also getType, etc. But honeslty I'm with you on this, only
On Tue, Jul 10, 2018 at 11:18 AM, Marco Pivetta wrote:
> It's been a few weeks since this has first landed here, and we're just
> wasting time in relatively silly discussions at this point:
>
> - As I said earlier, this patch has already been tested against some
> extremely tricky scenarios, so
On Tue, Jul 10, 2018 at 12:21 PM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> I'm definitely ith you on this one Marco, typed properties is something
> userland asks since a long time and postponing it to 8.0 for "marketing"
> reasons might be very frustrating (well, we'll deal with
2018-07-10 11:18 GMT+02:00 Marco Pivetta :
> It's been a few weeks since this has first landed here, and we're just
> wasting time in relatively silly discussions at this point:
>
> - As I said earlier, this patch has already been tested against some
> extremely tricky scenarios, so from a
>
> If we're seeking for a benefit, it would be by turning this to a
>> ReflectionZval insteaf of ReflectionReference. There would be isRef, but
>> also getType, etc. But honeslty I'm with you on this, only refs make sense.
>>
>
> I'm wondering if there is any legitimate use for something like
Upon re-reading what you wrote, I realized that I in fact misread what you
wrote and you didn't make a decision on whether to push for including it in 7.3
or not (I guess I was reading what I was expecting/hoping to read and not what
was actually there...). Sorry for that, I did not mean to
On Tue, Jul 10, 2018 at 10:30 AM, Jan Ehrhardt wrote:
> While trying to make the mailparse extension fit for PHP 7.3 I ran into
> changes in the libmbfl API. I cannot find any documentation on this
> change.
>
> The change was introduced in this commit by nikic:
>
On 10.07.2018 at 10:55, Jan Ehrhardt wrote:
> Jan Ehrhardt in php.internals (Tue, 10 Jul 2018 10:30:33 +0200):
>> The change was introduced in this commit by nikic:
>> https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25
>
> What strikes me: this change was made to the
On 10.07.2018 at 10:30, Jan Ehrhardt wrote:
> While trying to make the mailparse extension fit for PHP 7.3 I ran into
> changes in the libmbfl API. I cannot find any documentation on this
> change.
>
> The change was introduced in this commit by nikic:
>
Heya!
Just some background on my -1 vote:
1. the `==` operator is already riddled with edge cases and complexity,
and it is overall advisable to stay away from it
2. comparison of value objects already works correctly with `==` (if we
don't consider edge cases like `'0.' == '0.0'`)
3. the
It's been a few weeks since this has first landed here, and we're just
wasting time in relatively silly discussions at this point:
- As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you
On 10 July 2018 at 04:02, Ryan wrote:
>
> defined("SOME_CONSTANT") or die("SOME_CONSTANT was not defined");
>
> However, this behaviour has nothing to do with the difference of precedence
> - rather this is due to short circuiting.
>
As your own next example demonstrates, it does rely on the
Jan Ehrhardt in php.internals (Tue, 10 Jul 2018 10:30:33 +0200):
>The change was introduced in this commit by nikic:
>https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25
What strikes me: this change was made to the master branch almost a year
ago, at the time PHP 7.2.0
While trying to make the mailparse extension fit for PHP 7.3 I ran into
changes in the libmbfl API. I cannot find any documentation on this
change.
The change was introduced in this commit by nikic:
https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25
To be specific:
On Tue, Jul 10, 2018 at 10:36 AM Nikita Popov wrote:
> On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski wrote:
>
>>
>>
>> > -Original Message-
>> > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
>> > Golemon
>> > Sent: Monday, July 9, 2018 5:41 PM
>> > To: Christoph M.
On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski wrote:
>
>
> > -Original Message-
> > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> > Golemon
> > Sent: Monday, July 9, 2018 5:41 PM
> > To: Christoph M. Becker
> > Cc: Nikita Popov ; Kalle Sommer Nielsen
> > ;
On Mon, Jul 9, 2018 at 9:03 PM Ryan wrote:
> Hello all! Longtime PHP user, first-time contributor to internals (sorry
> if I screw anything up)!
>
> I'd like to propose either the deprecation (7.next - likely 7.4 at this
> point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and),
> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Monday, July 9, 2018 5:41 PM
> To: Christoph M. Becker
> Cc: Nikita Popov ; Kalle Sommer Nielsen
> ; Internals
> Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
>
> On
63 matches
Mail list logo
