On 7 Jul 2018, at 23:13, Zeev Suraski wrote:
>> -Original Message-
>> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
>> Golemon
>> Sent: Friday, July 6, 2018 10:36 PM
>> To: Christoph M. Becker
>> Cc: Nikita Popov ; s...@php.net; Björn Larsson
>> ; Dan Ackroyd ;
>>
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), and
T_LOGICAL_XOR (xor) tokens, or aliasing them to
On Tue, Jul 3, 2018 at 9:48 PM Michael Moravec wrote:
> Hello internals,
>
> The RFC for adding iterable_to_array() and iterable_count() is now open for
> voting:
>
> https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
>
> You can vote for each function separately.
>
> Voting will
Den man. 9. jul. 2018 kl. 21.22 skrev David Zuelke :
> Keep in mind you can do phpversion("extensionname"), so that function
> at least can't be removed, as the constant doesn't provide the same
> functionality.
Sure, but almost all of the core extensions return PHP_VERSION anyway
(thanks to
On Tue, Jun 26, 2018 at 6:32 PM Kalle Sommer Nielsen wrote:
>
> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov :
> > If you have a minor deprecation in mind, but were too lazy to write an RFC
> > for it, please write me a mail until tomorrow, so that it might be included
> > as part
Apologies for that middle discussion link, it was a bad hyperlink from a
bad paste if you look at source.
Here are the correct ones:
*Discussion:*
- https://externals.io/message/102337
- https://externals.io/message/102473
On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen
wrote:
> Hi
Hi everyone,
With no further discussion and no objection to start voting on this RFC, I
would like to move forward with the vote, which requires a 2/3 majority to
pass.
*RFC*: https://wiki.php.net/rfc/object-comparison
Discussions:
- https://externals.io/message/102337
I voted no.
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
making mistakes just because we already made
On 09.07.2018 at 16:40, Sara Golemon wrote:
> On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker wrote:
>
>> Sorry, that there has not been any decision yet. However, Sara
>> suggested that this decision is not solely up to the RMs[1], and I
>> wouldn't know how to decide it then[2], since
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
some
On Mon, Jul 9, 2018 at 11:18 AM, Levi Morrison wrote:
> Can you prove this somehow? Based on how `use function my\assert;`
> works a call to `assert()` later in that file should appear to engine
> as `my\assert`, not `assert`.
>
The vote is on deprecating (and ultimately blocking) the
On Mon, Jul 9, 2018 at 8:43 AM Sara Golemon wrote:
>
> On Mon, Jul 9, 2018 at 5:57 AM, Marco Pivetta wrote:
> > Something unclear to me here: is the removal of `assert()` affecting also
> > my own`my\assert()` (imported via `use function`)?
> >
> Yes, but in fairness, your namespaced assert
Alright, voted "NO" on that one then - namespaced stuff should have
whichever symbol name without colliding with internals
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Mon, Jul 9, 2018 at 4:42 PM, Sara Golemon wrote:
> On Mon, Jul 9, 2018 at 5:57 AM, Marco Pivetta
I called for use-cases and practically nobody responds and you put it
to vote, discarding nearly all advice you were given?
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jul 9, 2018 at 5:57 AM, Marco Pivetta wrote:
> Something unclear to me here: is the removal of `assert()` affecting also
> my own`my\assert()` (imported via `use function`)?
>
Yes, but in fairness, your namespaced assert function is already a bit
broken if you're not expecting it to be
On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker wrote:
> Sorry, that there has not been any decision yet. However, Sara
> suggested that this decision is not solely up to the RMs[1], and I
> wouldn't know how to decide it then[2], since there has been at least
> one objection[3].
>
To
On Sat, Jul 7, 2018 at 6:46 PM Yasuo Ohgaki wrote:
>
> I would like to vote to "yes".
> However, RFC does not have benchmark result. Do you have some results?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
Yasuo,
I have documented a benchmark based on my last comment. This benchmark
Hi,
as the discussion got no new contributions I'd like to start the voting
for the RFC fo add new functions for the handling of outer array elements.
https://wiki.php.net/rfc/array_key_first_last
To have a better separation I split up the vote for the functions. The
first vote covers the
Den 2018-07-07 kl. 23:12, skrev Zeev Suraski:
-Original Message-
From:p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
Golemon
Sent: Friday, July 6, 2018 10:36 PM
To: Christoph M. Becker
Cc: Nikita Popov;s...@php.net; Björn Larsson
; Dan Ackroyd;
Stanislav Malyshev; Marco
Something unclear to me here: is the removal of `assert()` affecting also
my own`my\assert()` (imported via `use function`)?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Mon, Jul 9, 2018 at 10:47 AM, Nikita Popov wrote:
> Hi,
>
> I would like to start voting on
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: some extensioms suffer from the fact that the macro
On Sun, Jul 8, 2018 at 8:36 PM, Nicolas Grekas wrote:
>
> Before talking about solutions, can the people who need this first outline
what functionality is needed and what it is needed for (and maybe what
workarounds you currently use). E.g. do you only need to know whether
On Mon, Jul 9, 2018 at 10:36 AM, Nikita Popov wrote:
> Hi,
>
> I would like to open the vote on the RFC for the deprecation (in PHP 7.3)
> and removal (in PHP 8.0) of case-insensitive constants.
>
> https://wiki.php.net/rfc/case_insensitive_constant_deprecation
>
> If you missed the discussion
Hi,
I would like to start voting on the "Deprecation for PHP 7.3" RFC, which
combines six minor deprecation proposals:
https://wiki.php.net/rfc/deprecations_php_7_3
Each deprecation is voted separately and will require a 2/3 majority
independently of whether it is a language or library change.
Hi,
I would like to open the vote on the RFC for the deprecation (in PHP 7.3)
and removal (in PHP 8.0) of case-insensitive constants.
https://wiki.php.net/rfc/case_insensitive_constant_deprecation
If you missed the discussion for this RFC, you can read up on it here:
25 matches
Mail list logo
