Re: [PHP-DEV] Strict switch statements

[Andrey Andreev]

Hi,

On Thu, Jun 14, 2018 at 7:53 AM, Sara Golemon  wrote:
> Just for casual discussion at this point:
> https://github.com/php/php-src/pull/3297
>
> switch ($a) {
>   case FOO:
>   // Works exactly as current behavior.
>   break;
>   case == FOO:
>  // Nearly identical, though not using the ZEND_CASE optimization.
>  // Can probably make this equivalent to `case FOO`, but it felt
> like an interesting direction.
>  break;
>   case === FOO:
>  // Only triggers if `$a === FOO`, no type juggling
>  break;
> }
>
> Love it? Hate it? See obvious flaws?  The implementation is just a
> rushed proof of concept, not something I've labored over, it may well
> have bugs.  Certainly wouldn't target anything earlier than 7.4, if at
> all.
>

I love it for the === part. Countless times I've had to avoid switch
statements because they can't do strict comparisons.

Cheers,
Andrey.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Strict switch statements

[Sara Golemon]

Just for casual discussion at this point:
https://github.com/php/php-src/pull/3297

switch ($a) {
  case FOO:
  // Works exactly as current behavior.
  break;
  case == FOO:
 // Nearly identical, though not using the ZEND_CASE optimization.
 // Can probably make this equivalent to `case FOO`, but it felt
like an interesting direction.
 break;
  case === FOO:
 // Only triggers if `$a === FOO`, no type juggling
 break;
}

Love it? Hate it? See obvious flaws?  The implementation is just a
rushed proof of concept, not something I've labored over, it may well
have bugs.  Certainly wouldn't target anything earlier than 7.4, if at
all.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Stanislav Malyshev]

Hi!

> That said, in my opinion it is too late for 7.3 to move a bundled
> extension to PECL, except perhaps for unresolved or even unresolvable
> security reasons.  ext/wddx comes to mind, and maybe there are others.

I'd be happy to move wddx if nobody steps up to maintain it. It has tons
of security issues lately (not even sure all are fixed) and it hard to
make heads or tails in it without really deep dive, for which I don't
think I have time, and nobody else seems to. And since it's a kinda
obscure format which in 99% of cases can be replaced by json I suspect...

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 12.06.2018 at 22:09, Stanislav Malyshev wrote:

> Yes, I think having some rules on maintainership would be nice, right
> now I haven't even considered extensions which have maintainers listed
> but no longer active, etc. - though I suspect those exist too. […]

>From looking at current EXTENSIONS[1], it seems to be rather the other
way round, unfortunately.

[1]


-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][Under Discussion] Add functions array_key_first() andarray_key_last()

[Christoph M. Becker]

On 13.06.2018 at 21:26, Enno Woortmann wrote:

> I've changed the status of the currently introduced RFC to add the
> functions array_key_first() and array_key_last() to "Under Discussion".
> 
> https://wiki.php.net/rfc/array_key_first_last

Thanks for working on this, Enno!

I suggest to address Côme's suggestion[1] on this mailing list and
especially in the RFC (the template[2] offers “Open Issues” and
“Rejected Features” sections).

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 13.06.2018 at 16:48, Sara Golemon wrote:

> On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev  
> wrote:
>
>> I'm not sure it's too late for 7.3. If we see that the extension is
>> unmaintained, we could move it out for 7.3 I think.
>
> Well, you and cmb are the RMs for 7.3, so you get the largest say in
> that, but IMO we won't finish sorting out the RFC and get through vote
> in time for feature freeze and pulling out whole extensions feels like
> a pretty hefty change to make at that point.  Yes, the extensions
> still exist in PECL, so I wouldn't vote down based on the timeline,
> but it does make me nervous.

The “Release Process” RFC states[1]:

| But they [the roles of the RMs] are not:
| * Decide which features, extension or SAPI get in a release or not

That said, in my opinion it is too late for 7.3 to move a bundled
extension to PECL, except perhaps for unresolved or even unresolvable
security reasons.  ext/wddx comes to mind, and maybe there are others.

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 12.06.2018 at 23:33, Stanislav Malyshev wrote:

>>> I'm afraid this might be misused.  It's too easy to update the year
>>> number, without actually doing *any* real maintenance work (“I'll come
>>> back to that later” …).  Some automated process would be nice, but
>>> manually checking the bug tracker for maintenance work (particularly
>>> wrt. security issues), and/or the commit log seems to be okay for now.
>>
>> That sounds like you're looking for a technical solution to an
>> organisational / social problem: if someone lists themselves as a
>> maintainer, they are making a commitment to volunteer their effort. That
>> commitment could be defined somewhere if it's not already, but it's
>> never going to be an automatically measurable SLA.
> 
> I agree here. If somebody cares enough to update the number, and by that
> commit to maintainership, this is already more than halfway towards the
> solution. We can never force anyone to be an active maintainer, or to
> allocate specific amount of time to fixing bugs or develop features, but
> the problem now is that we don't even have anybody in any maintainership
> capacity. We've had some people listed that haven't been active for
> years, and just remain there by default. I think once we solve this
> problem and have explicit commitment from maintainers, the question of
> how to make this commitment turn into a real work will be much better
> problem to have. We will still have to deal with it, obviously, but I
> think we first have to even get there.

Okay, you've convinced me. :)

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hello internals,

I've changed the status of the currently introduced RFC to add the 
functions array_key_first() and array_key_last() to "Under Discussion".


https://wiki.php.net/rfc/array_key_first_last

Regards,

Enno



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Sara Golemon]

On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev  wrote:
> I'm not sure it's too late for 7.3. If we see that the extension is
> unmaintained, we could move it out for 7.3 I think.
>
Well, you and cmb are the RMs for 7.3, so you get the largest say in
that, but IMO we won't finish sorting out the RFC and get through vote
in time for feature freeze and pulling out whole extensions feels like
a pretty hefty change to make at that point.  Yes, the extensions
still exist in PECL, so I wouldn't vote down based on the timeline,
but it does make me nervous.

> Sounds like a good idea. If you'd like, please feel free to edit
> the RFC to add a section about public notice procedure before
> moving. Otherwise, we could just make the procedure separately,
> it doesn't *have* to be part of the RFC.
>
As it stands now, the RFC needs a fair amount of refactoring to make
it about general ownership/abandonment process long term.  I can
shoehorn this public notice bit in, but it's going to feel weird until
a larger rewrite is done.  Are you planning to do that? Should cmb
since he resurrected the RFC? Open season for whomever cares?

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables

[Dmitry Stogov]

On Jun 10, 2018 10:46 PM, "Hoffman, Zachary Robert"  wrote:
>The existence of anything that internally relies on `get_defined_vars()` is a
>blocker for applying further optimisations to the engine (think stack frames),
>which is probably why Dmitry suggested its removal.

I did not know it was an optimization issue.

Accessing variables by name is a problem for optimimisation and JIT-ing, 
because we lose data-flow dependencies. But, this is not the end of the world. 
We just don't optimize functions that use this "bad" pattern.

Thanks. Dmitry.




I suppose I could substitute a userland equivalent:

function compact_(array $compact, array $vars)
{
return array_intersect_key($vars, array_flip($compact));
}

which changes A::c() to

function c()
{
$d = $this->d();
$a = pow($d, $d + 1);
$c = $a ^ 0b1100;
$b = $a - $d;

return new B(
compact_(
$this->b(),
get_defined_vars()
)
);
}

That is not so bad. As far as I am concerned, deprecate away.