Re: [PHP-DEV] Unifying logical operators

[Ryan]

 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".  I'm sorting by stars, but I can
definitely also check any dependencies if they aren't already in the list.


>
> For example, I know xor is used in PHP Codesniffer which while likely not
> often part of deployed code is very often a devel dependency.
>
> I think phpunit also uses xor and is also very popular.
>
> I use xor myself but my use is purely hobby (I have a pseudo-RNG written
> in PHP that can take any source of data, random or not, and pass it through
> a filter that makes it pass pRNG tests - showing that passing tests doesn't
> mean a random source is necessarily random enough for cryptography)
>
> Anyway as I believe you have already conceded, nuking xor would require
> many projects used a lot to have to change.


I'm absolutely not trying to take away behaviour with real use cases like
xor.  That's why I'm leaning more heavily on the aliasing side so it would
break very little code.  If the decision was made to remove the text
operators (or whatever the proper name for and, or, and xor is), there
would need to be a symbolic xor operator.



On Tue, Jul 10, 2018 at 11:37 PM, Walter Parker  wrote:

> There are 67 Million repositories on GitHub, is picking the top 30 PHP
> projects a representative sample of PHP use across the Internet?
> 80% of web servers where the back end language was known had PHP according
> to a recent survey.
> Picking 30 popular open source projects might bias the results of what you
> think is going in PHP usage.


Of course not - I'm working on expanding the search (right now to 300, and
then I'll probably do 3,000 overnight) as we speak and I'll go as far as my
hard drive (and patience, and GitHub API) will allow.  I don't really know
of a good way to get usage metrics for a token beyond "get some code using
PHP and check for the token".

Re: [PHP-DEV] Unifying logical operators

[Walter Parker]

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 together is a third style.
>>>
>>> This feels like a Python PEP request. By that I mean that Python wants to
>>> have only one way to do any one task. Perl style is there’s more than one
>>> way to do it.
>>>
>>> PHP has been a mix of these styles.
>>>
>>> The big question I have is how much PHP code will break due to an
>>> enforced
>>> style requirement?.
>>>
>>>
>> As I said in the OP, out of the top 30 GitHub repositories (the first page
>> on the API since I couldn't figure out how to get to the second), there
>> was
>> only one line that would require a change (and it was copy-pasted from the
>> manual).  Obviously there's no way to truly know how many times it's used
>> in non-public code, but I'll expand my GitHub search and report back some
>> more solid metrics.
>>
>
> Using github may not be the most reliable method.
>
>
There are 67 Million repositories on GitHub, is picking the top 30 PHP
projects a representative sample of PHP use across the Internet?
80% of web servers where the back end language was known had PHP according
to a recent survey.
Picking 30 popular open source projects might bias the results of what you
think is going in PHP usage.


Look at what is most popularly used in composer dependencies.
>
> For example, I know xor is used in PHP Codesniffer which while likely not
> often part of deployed code is very often a devel dependency.
>
> I think phpunit also uses xor and is also very popular.
>
> I use xor myself but my use is purely hobby (I have a pseudo-RNG written
> in PHP that can take any source of data, random or not, and pass it through
> a filter that makes it pass pRNG tests - showing that passing tests doesn't
> mean a random source is necessarily random enough for cryptography)
>
> Anyway as I believe you have already conceded, nuking xor would require
> many projects used a lot to have to change.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Unifying logical operators

[Alice Wonder]

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 Python wants to
have only one way to do any one task. Perl style is there’s more than one
way to do it.

PHP has been a mix of these styles.

The big question I have is how much PHP code will break due to an enforced
style requirement?.



As I said in the OP, out of the top 30 GitHub repositories (the first page
on the API since I couldn't figure out how to get to the second), there was
only one line that would require a change (and it was copy-pasted from the
manual).  Obviously there's no way to truly know how many times it's used
in non-public code, but I'll expand my GitHub search and report back some
more solid metrics.


Using github may not be the most reliable method.

Look at what is most popularly used in composer dependencies.

For example, I know xor is used in PHP Codesniffer which while likely 
not often part of deployed code is very often a devel dependency.


I think phpunit also uses xor and is also very popular.

I use xor myself but my use is purely hobby (I have a pseudo-RNG written 
in PHP that can take any source of data, random or not, and pass it 
through a filter that makes it pass pRNG tests - showing that passing 
tests doesn't mean a random source is necessarily random enough for 
cryptography)


Anyway as I believe you have already conceded, nuking xor would require 
many projects used a lot to have to change.



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

Re: [PHP-DEV] Unifying logical operators

[Ryan]

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 one way to do any one task. Perl style is there’s more than one
> way to do it.
>
> PHP has been a mix of these styles.
>
> The big question I have is how much PHP code will break due to an enforced
> style requirement?.
>

As I said in the OP, out of the top 30 GitHub repositories (the first page
on the API since I couldn't figure out how to get to the second), there was
only one line that would require a change (and it was copy-pasted from the
manual).  Obviously there's no way to truly know how many times it's used
in non-public code, but I'll expand my GitHub search and report back some
more solid metrics.

Removing them for style seems like it would be a big BC break. Aliasing
> them might lead to more subtle bugs in legacy code.
>

PHP 7 code should never be blindly upgraded to PHP 8 (which is what this
would target for actual changes, not just deprecation/notices).  This would
have to be clearly stated in the upgrade guide.


On Tue, Jul 10, 2018 at 5:01 AM, Rowan Collins 
wrote:
>
>
> As your own next example demonstrates, it does rely on the difference in
> precedence, because without it, you could only use this idiom after
> carefully checking that the left-hand side would be evaluated in one go,
> and probably using an extra set of parentheses.
>

The defined or die idiom does not depend on precedence, because it doesn't
contain an assignment operator.  One could theoretically do
$isDefined=defined("X") or die() - however that would be pointless as
$isDefined would always be true.


> > ($gdImage = @imagecreatetruecolor(120, 20)) || die('Cannot Initialize
> new GD image stream');
>
> This is less readable both because of the extra parentheses, and because
> the || operator is not as easily read as the English word "or".
>

The readability issue is why I included the option to alias to or.  I
definitely agree that x() or die() looks better than x()||die().


>
> 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).
>

Forgive my lack of knowledge with perl, but it looks[1] like they only
support a postfix if and postfix unless operators - which can serve the
same purpose as PHP's and/or (x and y => y if x, x or y => y unless !x).
However, I'm not aware of any language that uses and/or for this
behaviour.  I doubt there will be sufficient cause for confusion with perl
as many languages have slightly different behaviours for and/or (and
whether they use the text or symbolic versions).  Lua and python use
and/or, but don't convert the result to boolean and C{,#,++} use symbolic
and convert the result to boolean.  I don't know of a language that uses
and/or in this way (unless I'm wrong about Perl) to denote a postfix
operator.


>
> IF there is sufficient harm in having the extra operators, I would say
> removal is the only option - making them behave as aliases for || etc would
> just lead to even more confusion when they *don't* work the same way as in
> Perl, and in earlier versions of PHP. I'm not 100% convinced by the harm,
> though.
>

My thought for aliasing is that it may help with legacy code (if you're not
relying on the return value, which is 99% of cases), as well as there being
no symbolic equivalent for xor (as you state below it's not equivalent to
!= as I thought)


>
>
> Finally, a note on the "xor" operator - your draft says that this is
> equivalent to "!=", but that is not the case, because both can operate on
> non-boolean values. Consider "1 != 2" (true) vs "1 xor 2" (false). I don't
> think I've ever had a use for logical xor in PHP code, but there isn't
> anything to confuse it with, so no reason to remove it.
>

Ah, my mistake.  My only experience with xor was one class that I sat in on
in the middle of the semester.  It may be worth adding a symbolic
representation of xor regardless.




On Tue, Jul 10, 2018 at 2:37 PM, Kalle Sommer Nielsen  wrote:

>
> I personally wanted to extend this syntax but I never got around to it
> to support: "do() or throw new Exception(...);", tho its just a code
> style over: "if(!do()){ throw new Exception(...); }"
>

do() or throw doesn't actually work because throw is a language construct,
not a function.
$ php -r 'false or throw new Exception();'
PHP Parse error:  syntax error, unexpected 'throw' (T_THROW) in Command
line code on line 1

I actually ran into this at work today writing a bootstrap function.  I had
a function that would return a class that would either give the path to a
file in a subdirectory, or null if it didn't exist.  I was attempting to
call it like $file=self::findFile("subdirectory") and 

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Levi Morrison]

(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: http://www.php.net/unsub.php

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Levi Morrison]

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 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 same mistake.
> > >
> >
> > I voted no for the same reason. I'd even say that introducing a new array_
> > function that still accepts non arrays just to return null with a warning
> > doesn't make sense at this point.
> >
> > With that said, I'd gladly vote yes if there would be a way to distinguish
> > array_value_first([]) from array_value_first([0 => null]).
> >
> > Regards,
> > Pedro
>
> To safely use it a call to empty or count or something needs to happen:
>
> if (!empty($array)) {
> $value = array_value_first($array);
> // do something with $value
> }
>
> This is okay, but not great. Compare that to the design that returns a
> tuple though:
>
> if ([$_, $value] = array_first($array)) {
> // do something with $value
> }
>
> People who argue against the tuple because they don't like the design
> need to consider the bigger picture. The tuple way is less code,
> serves more use cases with fewer functions, and I even [implemented
> it][1]. If the array destructuring behavior seems unclear we can
> simply put an example in the manual pages for these functions --
> problem solved.
>
> This is not how RFC feedback should be handled. I hope more people
> vote no so we can reject this do it properly.

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

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Levi Morrison]

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 we already do this in other array_* functions, but we
> > cannot keep making mistakes just because we already made same mistake.
> >
>
> I voted no for the same reason. I'd even say that introducing a new array_
> function that still accepts non arrays just to return null with a warning
> doesn't make sense at this point.
>
> With that said, I'd gladly vote yes if there would be a way to distinguish
> array_value_first([]) from array_value_first([0 => null]).
>
> Regards,
> Pedro

To safely use it a call to empty or count or something needs to happen:

if (!empty($array)) {
$value = array_value_first($array);
// do something with $value
}

This is okay, but not great. Compare that to the design that returns a
tuple though:

if ([$_, $value] = array_first($array)) {
// do something with $value
}

People who argue against the tuple because they don't like the design
need to consider the bigger picture. The tuple way is less code,
serves more use cases with fewer functions, and I even [implemented
it][1]. If the array destructuring behavior seems unclear we can
simply put an example in the manual pages for these functions --
problem solved.

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.

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

Re: [PHP-DEV] Unifying logical operators

[Rowan Collins]

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 as though 
it's some kind of well-researched resource rather than the ramblings of 
one rather opinionated developer.


That's one of the more reasonable pages, but it's still an awful lot of 
words and spurious diagrams to say "coercing values means comparisons 
are intransitive in certain situations (most of which you'd never notice 
in every day use)".


Regards,

--
Rowan Collins
[IMSoP]


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

RE: [PHP-DEV] On not rushing things at the last minute

[Anatol Belski]

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, 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 around this time.  This isn't even new,
> > though it seems like it's becoming more commonplace with the adoption
> > of the yearly cadence.
> 
> Yeah, I think it is natural (when deadline is closing in, people start to 
> rush in), but
> not good. And I would feel for big features, like typed properties or friend
> classes (without touching its merits) I think they should target 7.4.
> 
> In the future, I think the expectation should be that if you have a large
> improvement it should not be expected to land in the version that is already 
> in
> the release cycle, even before feature freeze (especially if "before" is 
> measured
> in mere days). Large features take time to figure out and stabilize, and that
> should be the expectation. So you can write the RFC and open the vote
> whenever you want and whenever the life allows you the time to do it, but the
> expectation of where it lands should not be "immediately", especially for big
> ones.
> 
> What is "big" is subjective of course, but deep language level changes 
> (typing,
> strictness, changing how major parts of language work, major language feature
> like, I dunno, named arguments?) are big, and most deprecations or individual
> function additions aren't.
> 
I'm on the same page with Sara and Stas. There was a similar situation with 7.0 
and the exception hierarchy changes. Even it was an alpha with a lot of other 
changes, there was a strong community demand and support. The feature was 
something completely new and different from the features establishing 
themselves over some years. That one however seemed dangerous for the 
stability. The decision was taken by the RFC vote, which had passed.

Some internal breaches are still allowed currently, while that is another 
matter in regard whether the user space functionality overwhelms. In some case, 
the internal stability concerning all the noncore stuff might be of more 
importance, sometimes it wouldn't. People might be busy and not get the RFC 
implementation earlier. Still, to keep the balance, IMHO we should have as a 
goal to have the feature freeze before the first alpha. Some nonintrusive RFC 
should be still applicable for the alpha or later, but a huge change should be 
excluded.

Particularly with the typed properties patch - I'm sure Nikita and Bob would 
stand for the follow up fixes. Github screams, that the community support is 
huge. The idea was also brought and discussed earlier already. I personally 
have a bellyache that this patch is brought that late and has some internal 
breaches. However there's the demand and the consent wit hRMs. We should 
rethink this kind of situation for the future release schedules and limit RFC 
to the time before alpha, in general. Limiting this to before alpha has 
sufficiently more buffer than limiting it before beta.

Regards

Anatol

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Stanislav Malyshev]

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 and no
> carrot.)

I am completely fine with that too. I don't see why 7.4 should be
deprecation-only if we have new pending features that are ready by 7.4.

> Finally, given the current situation where we have a whopping five (!!)
> RFCs with votes ending the day before feature freeze, I'd say postponing
> the schedule is a good idea even without any consideration to typed
> properties. Just landing something like the comparison overloading RFC on
> the day of feature freeze is not going to be pretty. We are quite obviously

I would be also against that, but the current voting pattern suggest the
vote may make the question moot anyway. That said, typed properties are
IMO much larger than comparison overloading RFC, which is still a bit
niche. I would be most happy to have both in 7.4 if they pass, but I
don't think it would be a major problem if comparison overloading one is
passed and we delay 7.3 a bit to accommodate it. But for typed
properties I think we should just target 7.4 and not even consider
rushing with it.

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

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

Re: [PHP-DEV] Unifying logical operators

[Michael Morris]

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), and
> T_LOGICAL_XOR (xor) tokens, or aliasing them to ||, &&, and !=
> respectively.
>

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


> 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.


 True, but that's still a lot of code to break. A *lot* of code.  Far too
much to consider changing this even at a major level I would think.

PHP if anything, is too pragmatic a language for this change.

Re: [PHP-DEV] Unifying logical operators

[Rowan Collins]

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 !$connected;

It seems more clear than $connected or die().

I in fact find that more unreadable as you first got to dig through
the error handling before you actually get to the logic that triggered
it.



A more readable syntax, if we were designing from scratch, might be to 
look at SmallTalk, where ifTrue and ifFalse are methods on the boolean 
class, so can appear post-fix after any boolean, giving you something like:


$connected ifFalse: die();


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Typed Properties

[Larry Garfield]

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 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, JIT, FFI) even though technically they could go into the next
> >> available minor.
> > 
> > Hi,
> > 
> > I'm trying to understand this argument better but there is something I'm
> > missing. Why would a feature like JIT (which would be transparent to the
> > user AFAIK) need to wait for a major other than marketing reasons?
> > Sorry in advance for the slightly off-topic question.
> 
> Major versions are in many respects "marketing" events.  They're an
> indicator that big changes have happened in the language, big enough to
> warrant a change in the major version.
> It's a relatively recent evolution that we decided to only make it possible
> to break compatibility in major versions (and it's a very positive
> evolution, without a doubt), but either way - compatibility breakage has
> never been the motivating factor behind a major release.  Major releases
> enable compatibility breakage, not the other way around.
> Major features have always gone into major releases (with one notable
> exception - PHP 5.3, which many argue was a de-facto major release).
> 
> While 'marketing' always played a role in designating a certain version as
> major - getting people more motivated to upgrade, bring positive vibes and
> attention around the language, etc. (as was the case with 7.0) - since the
> formal release process and the policy change to only allow compatibility
> breakage in major versions - these compatibility breakages actually, to a
> large degree, 'piggyback' on the major new features.  To make it more real
> - what would the migration to PHP 7 look like if it was all about the
> compatibility breakages, and not the performance boosts or for that matter
> - scalar type hints?  Both of these (performance boosts and scalar type
> hints) could easily go into 5.7 from a purely technical perspective.
> 
> Zeev

While the marketing angle is valid, Zeev, it seems predicated on the idea that 
there won't be any other major new-and-cool features developed between now and 
8.0.  I'm reasonably confident that someone will find some user-facing 
exciting thing to improve between now and 2020.  I know some people have plans 
they're already working on.

Conceptually, as Nicolas and you have both hinted at, PHP 7.x is the series 
where "typing got real".  From a user-facing/marketing perspective 7.x is all 
about performance and typing.  That's the through line.  Including typed 
properties in that makes logical sense, marketing-wise, and would be a fitting 
capstone to the 7.x series in that regard.  

That's true regardless of whether typed properties go into 7.3 or 7.4; if 
given the timing they need to wait for 7.4 to have some extra polish done 
that's entirely reasonable, IMO, and doesn't change the underlying point.

However, mixing "no new features in 7.4/8.0, just the engine changes" with "we 
need a big showy thing in 8.0 to help sell it", er, feels like a 
contradiction.  It makes it sound more like "borrowing" a feature from 7.3 
(typed properties) for 8.0 for purely marketing purposes, and then also 
blocking any other features, so that we know 2 years out "the only interesting 
thing in 8.x will be typed properties, because that was written when 8.x was 
still just a twinkle in the eye but we sat on it".  That feels very 
disingenuous.

I am sure that's not your intent but those two statements together ("minimize 
features for 8.0" and "save this feature for 8.0 for marketing") just don't 
fit together in my mind in a nice way.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] Unifying logical operators

[Kalle Sommer Nielsen]

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 $connected or die().

I in fact find that more unreadable as you first got to dig through
the error handling before you actually get to the logic that triggered
it.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] On not rushing things at the last minute

[Rowan Collins]

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 announcing, e.g. typed properties


2) Quicky features: Simple changes which people have been *mentally* 
working on, often just deprecations and edge-case handling changes


3) Sleeping RFCs: Changes which enter initial discussion, go quiet, and 
sit in "Under Discussion" without reaching a vote


In all three cases, I think the general psychology of deadlines comes 
into play: it's easy to put off those finishing touches when you've got 
plenty of time, then jump into action at the last minute. There seems to 
also be a reluctance to target anything other than the current cycle; 
partly just because "would you like it released in 6 months or 18 
months?" is usually "sooner!"



One thing that might help, particularly with the 1st and 3rd categories 
there, is a clearer set of statuses for RFCs and other features.


We currently have 61 RFCs in the "Under Discussion" section of 
https://wiki.php.net/rfc; some of these are effectively abandoned, 
others just need polishing and taking to a vote. Then there are any 
number of experiments and TODO lists which could turn into a "submarine" 
or "quicky" feature.


I'm not sure of the exact formula, but some possible lines of thought...

- Have a separate status, or a separate list (dare I call it a 
"roadmap"?) for the RFCs targeting each release?

- Include items on that list that aren't ready for an RFC yet?
- Find some way to prune that list at key points in the release cycle?
- Have some kind of inactivity timeout for what counts as "Under 
Discussion"? Maybe a new status/heading of "Dormant"?
- Have a "put up or shut up" deadline? e.g. if you announce a feature 
targeting 7.4 now, you have to put it to vote by, say, March, not keep 
it ticking over until next July


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Unifying logical operators

[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 $connected or die().

Em ter, 10 de jul de 2018 às 15:59, Andrey Andreev 
escreveu:

> 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 <
> la...@garfieldtech.com>:
> >> "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 support: "do() or throw new Exception(...);", tho its just a code
> > style over: "if(!do()){ throw new Exception(...); }"
> >
>
> I sometimes declare a closure that throws an exception to do just
> that. It's very convenient in short(ish) scripts.
>
> isset($foo) OR $foo = 'bar'; (and similar variations using empty()
> and/or &&) is another pattern I use often to set fallback values for
> empty or missing inputs.
>
> An eventual deprecation would make literally all of my code output
> entire screens of warnings.
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
David Rodrigues

Re: [PHP-DEV] Unifying logical operators

[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 personally wanted to extend this syntax but I never got around to it
> to support: "do() or throw new Exception(...);", tho its just a code
> style over: "if(!do()){ throw new Exception(...); }"
>

I sometimes declare a closure that throws an exception to do just
that. It's very convenient in short(ish) scripts.

isset($foo) OR $foo = 'bar'; (and similar variations using empty()
and/or &&) is another pattern I use often to set fallback values for
empty or missing inputs.

An eventual deprecation would make literally all of my code output
entire screens of warnings.

Cheers,
Andrey.

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

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Pedro Magalhães]

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 making mistakes just because we already made same mistake.
>

I voted no for the same reason. I'd even say that introducing a new array_
function that still accepts non arrays just to return null with a warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro

Re: [PHP-DEV] On not rushing things at the last minute

[Stanislav Malyshev]

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 chaos every year around this time.  This isn't even new,
> though it seems like it's becoming more commonplace with the adoption
> of the yearly cadence.

Yeah, I think it is natural (when deadline is closing in, people start
to rush in), but not good. And I would feel for big features, like typed
properties or friend classes (without touching its merits) I think they
should target 7.4.

In the future, I think the expectation should be that if you have a
large improvement it should not be expected to land in the version that
is already in the release cycle, even before feature freeze (especially
if "before" is measured in mere days). Large features take time to
figure out and stabilize, and that should be the expectation. So you can
write the RFC and open the vote whenever you want and whenever the life
allows you the time to do it, but the expectation of where it lands
should not be "immediately", especially for big ones.

What is "big" is subjective of course, but deep language level changes
(typing, strictness, changing how major parts of language work, major
language feature like, I dunno, named arguments?) are big, and most
deprecations or individual function additions aren't.

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

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

Re: [PHP-DEV] Unifying logical operators

[Kalle Sommer Nielsen]

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 support: "do() or throw new Exception(...);", tho its just a code
style over: "if(!do()){ throw new Exception(...); }"



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Unifying logical operators

[Larry Garfield]

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 different feature again).
> 
> It seems to me the “do this or die” idiom at least has been very common
> in PHP.  There may still be some occurences in the manual proper, and
> definitely there are occurences in user contributed notes.

"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 haven't seen it in actual production code in about 14 yeas, I think, and 
anyone who tried submitting it would get their patch rejected so hard it would 
make their head spin.  It's a terrible pattern outside of fly-by-night 
tutorials.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] Re: [VOTE] Deprecate and remove case-insensitive constants

[Niklas Keller]

> 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 constants, function names are case-insensitive, and a fallback
> could be added to constant accesses to return a closure of the function
> with the same name if no constant is found.
>
> Of course, removing case-insensitive constants wouldn't preclude such a
> feature, just make it a little more annoying to implement, so this is
> not really a significant reason to vote against. To that end, I'll vote
> in favour of this deprecation.

No, thanks. The fallback is already a bad thing for functions, we
don't need another one.

If such a feature would be implemented, it'd probably be via combined
symbol tables, making either everything case-insensitive or everything
case-sensitive.

Regards, Niklas

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

Re: [PHP-DEV] [VOTE] Deprecations for PHP 7.3

[Niklas Keller]

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()`. Whether
the function is jumped around or not depends on `zend.assertions`,
which is highly surprising, because it also jumps around `assert()` in
namespaced code even if an `assert()` function exists in that
namespace. Requiring an explicit `use function` is really weird.

See https://3v4l.org/8EKdA for an example. The behavior in PHP 7.0+ is
by-design and mentioned in the original assertions RFC.

Regards, Niklas
Am Mo., 9. Juli 2018 um 17:18 Uhr schrieb Levi Morrison :
>
> 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 function is already a bit
> > broken if you're not expecting it to be elided in production
> > environments.
> >
> > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> 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`.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] On not rushing things at the last minute

[Andrey Andreev]

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 habit of seeing months of quiet followed by
> weeks of chaos every year around this time.  This isn't even new,
> though it seems like it's becoming more commonplace with the adoption
> of the yearly cadence.
>
> What are the causes?
>

Aside from life keeping you busy until you realize it's that time of
the year again, I believe it's just the short development cycle and is
no coincidence that this has been happenning more often since getting
into a yearly schedule.

In my observation, adoption rates are slower than the release cycle
and so it's kind of like ... I barely got to enjoy the shiny new thing
and the next feature freeze is already happening. And then also, we're
always eager to get our idea in before feature freeze, but that's hard
to achieve unless we come up with it in January or earlier, but since
everybody's naturally got their eyes set on version.next, few people
think about X.Z before X.Y is released.

I don't know if this can be fixed though. It's just hard to keep up
with schedules on side projects and let's face it - PHP is nobody's
primary job, so any work spent on it is by definition a side project.

Cheers,
Andrey.

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

Re: [PHP-DEV] On not rushing things at the last minute

[Kalle Sommer Nielsen]

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 it was proposed to have PHP 5.7 as a deprecation/migration
friendly release but we ended just rolling with PHP7 and the migration
was merely flawless. Personally I don't like the idea of such type of
releases either, I think they make sense on paper but reality is also
that we have a branch to support for years to come as to our current
release policy.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] On not rushing things at the last minute

[Dustin Wheeler]

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 date can reliably be expected to occur around
> mid-July until and unless we change the GA date (FF is 18 weeks and 2
> days prior to GA, GA in turn is approximately 4 weeks before
> Christmas).  I'll admit that the publishing of the 7.3 timeline came
> very late this year and that's on myself and Remi.  The RM selection
> process should have started two months earlier than it did.
>

Yeah, I worded that pretty terribly. I should have put a parenthetical
after that if statement. Agree 100% on adequate annoucement.

> > and there was an agreed "best intentions" policy
> > to not submit RFCs that encroach on that date,
> >
> I had hoped there already was an agreement on this.  Seeing the SIX
> currently in voting makes me doubt that understanding is shared (okay,
> in fairness, Class Friendship isn't targeting 7.3).
>

Class Friendship is currently targeting the trash! :P

> > That, or subconsciously, the talk of a new version of
> > PHP sparked folks to get off their ass and put forth their ideas! :P
> >
> That's very likely a contributing factor, especially with talk of 7.4
> being deprecations focused (something I'm finding myself agreeing with
> less and less over time).  This isn't new to this year though, even if
> it's been less pronounced till now.
>

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?)

It can be frustrating, but I really like to see humans conversing and
finding flexible solutions for the greater good (which is already
happening here). Perhaps there is a reasonable way to document /
communicate the shared understanding that "sending new RFCs to a
release that's so close to feature freeze that it's questionable
whether voting will end in time" is bad form. Having a parenthetical
that covers "exceptional work" could also address situations like the
property types RFC, which ... not to minimize ANY other work on-going
... is in my opinion, worthy of such an exception.

Where would be a good place to document that? https://wiki.php.net/rfc/howto?

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Dan Ackroyd]

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 array_value_first()
and array_value_last()

A think a better pattern would be to return a tuple as Levi suggested.

[$key, $value] = array_first($array);
[$key, $value] = array_last($array);

For people not used to returning tuples.you should branch out a
bit and try using them.

They are a better pattern to  use when returning multiple values from
a function that don't need/deserve their own class/struct creating.

cheers
Dan
Ack


On 9 July 2018 at 18:31, CHU Zhaowei  wrote:
> 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 same mistake.
>
> Regards,
> CHU Zhaowei

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

[PHP-DEV] Re: [RFC] [VOTE] User-defined object comparison

[Rudolf Theunissen]

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 `compare_function`. When you use the operator,
it calls that function, which in turn does comparison tests and eventually
calls object handlers when comparing objects. This RFC is not suggesting
that we change the pointer of the operator, but instead adjust the
behaviour of `compare_function`, which the operator already points to.
Implementing `__compareTo` does affect the behaviour of the operator, but
it doesn't overload it. If in the future we wanted to add proper operator
overloading, there would be a function like `__spaceship` that directly
overloads the operator to change its pointer to something else. If this was
to happen, `__compareTo` would still be used by `compare_function`, and
used internally when sorting or searching. I realise that the behaviour of
the operator can be changed with `__compareTo`, and is therefore no
different to operator overloading, but that's not how we should look at
this. The reason why <=> normalises to -1,0,1 isn't because the operator
dictates that - it's `compare_function` that does that, which is what the
operator points to by default.

I hope that helps to clear things up a bit. :)

On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen 
wrote:

> 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
>  (June 21)
>   - https://externals.io/message/102473 (June 26)
>
> The vote will be open until 2018-07-16.
>
> Thank you,
> Rudi
>
>

Re: [PHP-DEV] Re: [RFC] [VOTE] User-defined object comparison

[Rudolf Theunissen]

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 wouldn't say it works *well*. Also no strict comparison.
3. We shouldn't need to ever use `method_exists()`? Everything can be
compared, so tests for implementation are effectively useless. If this is
not the case in the future we can introduce interfaces for Comparable and
Equatable that abstract and implied by the presence of the methods (Golang
style). I don't foresee this to ever happen though.
4. "Equal ordering implies equality" is primarily to keep consistent with
current behaviour - PHP doesn't treat them as separate things today.
5. This was a difficult trade-off between flexibility and consistency. I
opted for a wider approach that can be narrowed later if we really want to.

Happy to discuss further.

Rudi

On Tue, 10 Jul 2018 at 05:35, Marco Pivetta  wrote:

> 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 suggested approach is to add more interface-less reserved/magic
> methods: an `Eq` and an `Ord` class would have solved this much more
> elegantly and with clear type declarations that can be re-used in userland.
> With this patch, we have to rely on `method_exists()` instead.
>  4. It would also be much clearer to enforce that `Ord extends Eq`, rather
> than adding implicit "sorting implies equality" rules
>  5. "the methods are not restricted to instances of the same class" - this
> is something I disagree with, but we lack the type system facilities to
> declare the variance of the `Eq` and `Ord` operations for a specific class.
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On Mon, Jul 9, 2018 at 8:57 PM, Rudolf Theunissen <
> rudolf.theunis...@gmail.com> wrote:
>
>> 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 <
>> rudolf.theunis...@gmail.com>
>> wrote:
>>
>> > 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
>> >  (June 21)
>> >   - https://externals.io/message/102473 (June 26)
>> >
>> > The vote will be open until 2018-07-16.
>> >
>> > Thank you,
>> > Rudi
>> >
>> >
>>
>
>

Re: [PHP-DEV] On not rushing things at the last minute

[Thomas Hruska]

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 quiet followed by
weeks of chaos every year around this time.  This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.


-Sara


I'd like to see confirmed security vulnerabilities and bug squashing be 
made a priority over new features.


Bug #73535 is still open, unaddressed, and unmitigated...

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

Re: [PHP-DEV] Re: PHP 7.3 zif_handler changes

[Christoph M. Becker]

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: some extensioms suffer from the fact that the macro GC_G
> was removed from
> https://github.com/php/php-src/blob/master/Zend/zend_gc.h
> Some of the removed functionality has been reintroduced in gc_status
> https://github.com/php/php-src/commits/master/Zend/zend_gc.h
>
> Examples using GC_G: v8js, xdebug, tideways.
> v8js was using gc_active to check if garbage collection was running.
> I did a wild guess to fix it:
> https://github.com/Jan-E/v8js/commit/997df065d3cd06a9b11e399458c391
 eb797a850e#diff-dc446a69201ccda44a33d52f6c8c

 This looks wrong, since zend_gc_collect_cycles() actually triggers the
 GC, if I'm not mistaken.

 It seems to me that should be something like:

   zend_gc_status status;
   zend_gc_get_status();
   if (status.runs) {

>>>
>>> The correct way to handle this is to implement a proper get_gc() handler,
>>> which will be called in favor of get_properties() during GC.
>>
>> Ah, thanks!  In some other cases, for instance, in Xdebug[1], using
>> zend_gc_get_status() would be correct, wouldn't it?
>>
>> [1]
>> 
> 
> It should be - care to make a patch? :-) Xdebug also doesn't do the hash 
> protections correctly yet. I've not had the time to make a fix for that 
> yet either (hint!) ;-)

I'm already working on that.  I'll submit a (partial?) PR ASAP.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] On not rushing things at the last minute

[Peter Lind]

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 roadmap of major and minor
versions, along with set dates and deadlines that could not be moved, this
wouldn't be an issue.


>
> At the same time, I would hate to see a TON of additional process /
> voting constraints come as a response to this issue.
>
> That said, if feature freeze for a release is announced well in
> advance, published, and there was an agreed "best intentions" policy
> to not submit RFCs that encroach on that date, then I think all would
> be well. I don't think there's any intent to slide features in under
> the finish line. It just seems like a lot of ideas finished baking at
> a weird time. That, or subconsciously, the talk of a new version of
> PHP sparked folks to get off their ass and put forth their ideas! :P
>
>
>
I think a hard deadline would be a better solution. Past that date, it
simply doesn't matter what the RFC is about, it'll make the next version at
the earliest, not the current one. Movable feature freeze and release dates
do not benefit the language or its users, nor most of the core developers,
I'd say.

Just my take on it.

-- 
CV: https://stackoverflow.com/cv/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] On not rushing things at the last minute

[Sara Golemon]

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 unless we change the GA date (FF is 18 weeks and 2
days prior to GA, GA in turn is approximately 4 weeks before
Christmas).  I'll admit that the publishing of the 7.3 timeline came
very late this year and that's on myself and Remi.  The RM selection
process should have started two months earlier than it did.

> and there was an agreed "best intentions" policy
> to not submit RFCs that encroach on that date,
>
I had hoped there already was an agreement on this.  Seeing the SIX
currently in voting makes me doubt that understanding is shared (okay,
in fairness, Class Friendship isn't targeting 7.3).

> That, or subconsciously, the talk of a new version of
> PHP sparked folks to get off their ass and put forth their ideas! :P
>
That's very likely a contributing factor, especially with talk of 7.4
being deprecations focused (something I'm finding myself agreeing with
less and less over time).  This isn't new to this year though, even if
it's been less pronounced till now.

-Sara

1 - https://externals.io/message/102031#102031
2 - https://wiki.php.net/todo/php73

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

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

"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 at 0x07FEEC6E83C2 (php7.dll) in php.exe:
0xC005: Access violation reading location 0x00060BE02800.
occurred

Relevant part of the backtrace:

[Inline Frame] php7.dll!zend_mm_alloc_small(_zend_mm_heap *) Line 1285
[Inline Frame] php7.dll!zend_mm_alloc_heap(_zend_mm_heap * heap,
unsigned __int64) Line 1356
php7.dll!_emalloc(unsigned __int64 size) Line 2496
[Inline Frame] php_mailparse.dll!zend_string_alloc(unsigned __int64)
Line 133
[Inline Frame] php_mailparse.dll!zend_string_init(const char *) Line 155
php_mailparse.dll!mailparse_get_part_data(_php_mimepart * part,
_zval_struct * return_value)

It passes all tests in PHP 7.2.8 RC1.

I will make a PR and continue the discussion there.
-- 
Jan

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

Re: [PHP-DEV] On not rushing things at the last minute

[Dustin Wheeler]

>
> 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 Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I agree with Sara. This is definitely a worthwhile discussion and the
issue probably puts additional stress on RMs that may be easily
avoided.

Personally (for Class Friendship), I opted to target either 7.4 or 8.0
(whichever was decided to be next-in-line; but *specifically NOT* 7.3
due to more important discussions happening at the moment. So I think
there's some "personal judgment calls" to make for folks submitting
RFCs.

At the same time, I would hate to see a TON of additional process /
voting constraints come as a response to this issue.

That said, if feature freeze for a release is announced well in
advance, published, and there was an agreed "best intentions" policy
to not submit RFCs that encroach on that date, then I think all would
be well. I don't think there's any intent to slide features in under
the finish line. It just seems like a lot of ideas finished baking at
a weird time. That, or subconsciously, the talk of a new version of
PHP sparked folks to get off their ass and put forth their ideas! :P

Just my 2c, FWIW

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

[PHP-DEV] On not rushing things at the last minute

[Sara Golemon]

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 around this time.  This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.

What are the causes?

Is it seasonal? Some people have more time during the summer because
of school/family schedules?  Maybe the solution is to shift the
release window a few months in one direction or the other.

Is it failing to get our shit together?  Maybe we should discourage
late RFCs by requiring a higher voting threshold?  e.g. You can open
voting as ridiculously late as a week before feature freeze (honestly,
who would do that?) if you want, but you'll need an extra 10% to pass
on top of whichever threshold already applies.

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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Nikita Popov]

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 instead. I think I can safely say not just on
> > behalf on Bob and myself, but also on behalf of the wider PHP community,
> > that we are not willing to sit on this feature for 2.5~3 years until a
> > hypothetical PHP 8, even though it is essentially ready *now*. Of course,
> > this is not my decision to make, but as Sara put it, that's the writing
> on
> > 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 and no
> > carrot.)
> >
> > Finally, given the current situation where we have a whopping five (!!)
> > RFCs with votes ending the day before feature freeze, I'd say postponing
> > the schedule is a good idea even without any consideration to typed
> > properties. Just landing something like the comparison overloading RFC on
> > the day of feature freeze is not going to be pretty. We are quite
> obviously
> > rushing things right now, and I don't think keeping to some otherwise
> > arbitrary date is worth that.
>
> Good point!  Thus, I suggest to put in *one* additional alpha (i.e.
> postponing feature freeze by two weeks to 2018-07-31) in any case, have
> the vote on “Typed Properties” starting soon with explicit options which
> version these should be merged into, and if there will be an option to
> target PHP 7.3, *and* the voters decide it should go into PHP 7.3, to
> insert yet an additional alpha5.
>

That sounds like a very reasonable approach to me.

Anyhow, I strongly suggest to amend our voting and release rules to
> avoid such situations in the future.  Ending any vote one day or a few
> days before feature freeze should simply not be allowed (unless the RFC
> targets another version).  And there should be clear rules which
> circumstances warrant or allow to postpone feature freeze, and who's
> decision that is.
>

Ugh yes. A hard rule that no new RFCs targeting the branch can be submitted
4 or 5 weeks before the feature freeze would be reasonable and would avoid
this mess in the future. Especially if could get an announcement about the
approaching "RFC freeze" a month or so in advance.

Nikita

Re: [PHP-DEV] [RFC] Typed Properties

[Nicolas Grekas]

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 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, JIT, FFI) even though technically they could go into the next
>>> available minor.
>>>
>>
>> Hi,
>>
>> I'm trying to understand this argument better but there is something I'm
>> missing. Why would a feature like JIT (which would be transparent to the
>> user AFAIK) need to wait for a major other than marketing reasons?
>> Sorry in advance for the slightly off-topic question.
>>
>
> Major versions are in many respects "marketing" events.  They're an
> indicator that big changes have happened in the language, big enough to
> warrant a change in the major version.
> It's a relatively recent evolution that we decided to only make it
> possible to break compatibility in major versions (and it's a very positive
> evolution, without a doubt), but either way - compatibility breakage has
> never been the motivating factor behind a major release.  Major releases
> enable compatibility breakage, not the other way around.
> Major features have always gone into major releases (with one notable
> exception - PHP 5.3, which many argue was a de-facto major release).
>
> While 'marketing' always played a role in designating a certain version as
> major - getting people more motivated to upgrade, bring positive vibes and
> attention around the language, etc. (as was the case with 7.0) - since the
> formal release process and the policy change to only allow compatibility
> breakage in major versions - these compatibility breakages actually, to a
> large degree, 'piggyback' on the major new features.  To make it more real
> - what would the migration to PHP 7 look like if it was all about the
> compatibility breakages, and not the performance boosts or for that matter
> - scalar type hints?  Both of these (performance boosts and scalar type
> hints) could easily go into 5.7 from a purely technical perspective.
>
> Zeev
>


Just to clarify my previous statement: marketing is a good reason to bump a
major version. Doing so creates momentum after the release and motivation
before.

I just don't agree that typed properties are part of that. They are a
really natural and important feature, but not one that will allow anyone to
do anything new that wasn't possible before.
JIT and/or async are game changers. They don't play in the same category to
me.
Others might disagree of course, and I don't want to minimize their
importance nor the work of Nikita and Bob. Kudos to them actually.

Nicolas

>

Re: [PHP-DEV] Unifying logical operators

[Christoph M. Becker]

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); // int(3)
> 
> A consistent logical XOR with the same precedence as || and && could
> perhaps be spelled ^^, but there is no such operator in PHP.

Thanks.  I stand corrected!

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] Typed Properties

[Zeev Suraski]

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 be included in a major version, and not a minor
>> one (phpng, JIT, FFI) even though technically they could go into the next
>> available minor.
>>
>
> Hi,
>
> I'm trying to understand this argument better but there is something I'm
> missing. Why would a feature like JIT (which would be transparent to the
> user AFAIK) need to wait for a major other than marketing reasons?
> Sorry in advance for the slightly off-topic question.
>

Major versions are in many respects "marketing" events.  They're an
indicator that big changes have happened in the language, big enough to
warrant a change in the major version.
It's a relatively recent evolution that we decided to only make it possible
to break compatibility in major versions (and it's a very positive
evolution, without a doubt), but either way - compatibility breakage has
never been the motivating factor behind a major release.  Major releases
enable compatibility breakage, not the other way around.
Major features have always gone into major releases (with one notable
exception - PHP 5.3, which many argue was a de-facto major release).

While 'marketing' always played a role in designating a certain version as
major - getting people more motivated to upgrade, bring positive vibes and
attention around the language, etc. (as was the case with 7.0) - since the
formal release process and the policy change to only allow compatibility
breakage in major versions - these compatibility breakages actually, to a
large degree, 'piggyback' on the major new features.  To make it more real
- what would the migration to PHP 7 look like if it was all about the
compatibility breakages, and not the performance boosts or for that matter
- scalar type hints?  Both of these (performance boosts and scalar type
hints) could easily go into 5.7 from a purely technical perspective.

Zeev

Re: [PHP-DEV] Unifying logical operators

[Rowan Collins]

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 || and && could
perhaps be spelled ^^, but there is no such operator in PHP.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Unifying logical operators

[Christoph M. Becker]

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 very common
in PHP.  There may still be some occurences in the manual proper, and
definitely there are occurences in user contributed notes.

> Finally, a note on the "xor" operator - your draft says that this is
> equivalent to "!=", but that is not the case, because both can operate on
> non-boolean values. Consider "1 != 2" (true) vs "1 xor 2" (false). I don't
> think I've ever had a use for logical xor in PHP code, but there isn't
> anything to confuse it with, so no reason to remove it.

“xor” is equivalent to ^ (sans the precedence).

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] Typed Properties

[Pedro Magalhães]

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, JIT, FFI) even though technically they could go into the next
> available minor.
>

Hi,

I'm trying to understand this argument better but there is something I'm
missing. Why would a feature like JIT (which would be transparent to the
user AFAIK) need to wait for a major other than marketing reasons?
Sorry in advance for the slightly off-topic question.

Regards,
Pedro

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Christoph M. Becker]

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 also on behalf of the wider PHP community,
> that we are not willing to sit on this feature for 2.5~3 years until a
> hypothetical PHP 8, even though it is essentially ready *now*. Of course,
> this is not my decision to make, but as Sara put it, that's the writing on
> 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 and no
> carrot.)
> 
> Finally, given the current situation where we have a whopping five (!!)
> RFCs with votes ending the day before feature freeze, I'd say postponing
> the schedule is a good idea even without any consideration to typed
> properties. Just landing something like the comparison overloading RFC on
> the day of feature freeze is not going to be pretty. We are quite obviously
> rushing things right now, and I don't think keeping to some otherwise
> arbitrary date is worth that.

Good point!  Thus, I suggest to put in *one* additional alpha (i.e.
postponing feature freeze by two weeks to 2018-07-31) in any case, have
the vote on “Typed Properties” starting soon with explicit options which
version these should be merged into, and if there will be an option to
target PHP 7.3, *and* the voters decide it should go into PHP 7.3, to
insert yet an additional alpha5.

Anyhow, I strongly suggest to amend our voting and release rules to
avoid such situations in the future.  Ending any vote one day or a few
days before feature freeze should simply not be allowed (unless the RFC
targets another version).  And there should be clear rules which
circumstances warrant or allow to postpone feature freeze, and who's
decision that is.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] Typed Properties

[Zeev Suraski]

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 been tested against some
> > extremely tricky scenarios, so from a userland perspective it is safe for
> > inclusion. If you don't have confidence in something related to it,
> please
> > write a test case and help out.
> >  - can we get a yes/no from the RMs on whether we'll have the time window
> > to (potentially) get this voted and (*if* passed) merged? Shoot out a
> mail
> > with the decision, please. We could have a vote for which version to
> > include this in, if that's really such a big issue.
> >  - can we split out discussions on 8.0 scope? Minor versions are indeed
> for
> > features. If PHP 8.0 lacks interesting/marketing features, that's a
> > different story.
> >  - Nikita/Bob: can this be voted upon right after the RMs have taken a
> > decision? Anything blocking missing?
> >  - Is the reference issue reported by Nicolas a blocker? Nicolas, can you
> > clarify here?
> >
>
> 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 that if it happens
> :) )
>
>
For the sake of those who weren't reading the discussion on the other
thread - the reason I believe it shouldn't go into 7.3 as well as the
reasons why I think this should be discussed for 8.0 are hardly just
'marketing' reasons, although I absolutely do think that decisions like
this (which version a certain feature goes into) is not exclusively or even
primarily a technical decision.

The reasons I stated were:
"the little time we have left, the little concrete discussion that happened
so far as a result, the inconsistency of allowing such a vote to push out
feature freeze, the scope of this feature being a lot more suitable for a
major release, and our inability to fix/improve other related elements at
the same time"

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, JIT, FFI) even though technically they could go into the next
available minor.

Zeev

Re: [PHP-DEV] Introspection for references

[Nikita Popov]

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 refs make sense.
>>>
>>
>> I'm wondering if there is any legitimate use for something like this. The
>> only thing that comes to mind is comparing arrays by identity. E.g.
>> https://github.com/symfony/symfony/blob/master/src/Symfony/
>> Component/VarDumper/Cloner/VarCloner.php#L153 could check directly check
>> whether an array is the $GLOBALS array. It would also allow direct
>> recursion detection on arrays (ref https://stackoverflow.com/ques
>> tions/9105816/is-there-a-way-to-detect-circular-arrays-in-pure-php).
>> Doing the same on just references is nearly the same, but doesn't handle
>> the $GLOBALS case correctly.
>>
>
> Note that AFAIK, not only $GLOBALS has a special behavior, but also any
> "scope" array (the deprecated $context argument of error handlers at least,
> maybe what get_defined_vars() also?
>
> If we can return this info, I would definitely leverage it.
> If not, that's no blocker, I'll let you decide.
>
>
>
>> There is a 4th possibility: have a "ReflectionReference::getHash" method,
>>> that would return a unique string/id per reference (what
>>> symfony_zval_debug() does.)
>>>
>>
>> Is this the same as my 3rd suggestion with a different name
>>
>
> No, it's the same, I read too fast.
>
>
>
>> we could return the address hashed with a per-process key. This would
>> make the function somewhat slower though.
>>
>
> That's exactly what we do in our extension, inspired by spl_object_hash().
> On the perf side, a XOR should be OK :)
>

Unfortunately XOR is about as good as just returning the address directly.
XORing the value is basically doing a one-time-pad without the "one-time"
part, aka completely broken. If we wanted to actually hide the address,
we'd have to run it through a proper hash. (Then again, you are right that
spl_object_hash used to do this, so maybe we just don't care...)

Nikita

Re: [PHP-DEV] [RFC] Typed Properties

[Nikita Popov]

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 from a userland perspective it is safe for
> inclusion. If you don't have confidence in something related to it, please
> write a test case and help out.
>

Thanks a lot for your tests and feedback!


>  - can we get a yes/no from the RMs on whether we'll have the time window
> to (potentially) get this voted and (*if* passed) merged? Shoot out a mail
> with the decision, please. We could have a vote for which version to
> include this in, if that's really such a big issue.
>  - can we split out discussions on 8.0 scope? Minor versions are indeed for
> features. If PHP 8.0 lacks interesting/marketing features, that's a
> different story.
>  - Nikita/Bob: can this be voted upon right after the RMs have taken a
> decision? Anything blocking missing?
>

I've just updated the RFC with the last major change (switch to the "no
intrinsic types" alternative for reference handling). Apart from some minor
tweaks (maybe add a bit more information on how the implementation works)
the RFC itself should be about ready for voting.

Even if the RMs decide that this cannot go into PHP 7.3, we'd still like to
start voting on this RFC soon (in the next few days).

 - Is the reference issue reported by Nicolas a blocker? Nicolas, can you
> clarify here?
>

My plan for the reference reflection would be to write a separate RFC.
While typed properties make this more important, the feature itself is
really independent, and while we could slip it through as part of this RFC,
I think that this problem has a large enough design space that we should
discuss it separately.

Nikita

Re: [PHP-DEV] [RFC] Typed Properties

[Marco Pivetta]

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 that if it happens
> :) )
>
> But technically, it feels almost ready.
>
> The reference issue looks "easy" to fix(esp. when its not me doing it yes
> ;) ). It'd be better to have it at the same time, but I can wait the next
> version as I don't want to be the one with a blocker here, and also because
> I can write a "degraded mode" for now if that's the plan.
>

The important bit is to not have functionality that blocks userland
scenarios that previously worked.
If the try-catch works, then we can surely roll with it.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Typed Properties

[Nicolas Grekas]

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 userland perspective it is safe for
> inclusion. If you don't have confidence in something related to it, please
> write a test case and help out.
>  - can we get a yes/no from the RMs on whether we'll have the time window
> to (potentially) get this voted and (*if* passed) merged? Shoot out a mail
> with the decision, please. We could have a vote for which version to
> include this in, if that's really such a big issue.
>  - can we split out discussions on 8.0 scope? Minor versions are indeed for
> features. If PHP 8.0 lacks interesting/marketing features, that's a
> different story.
>  - Nikita/Bob: can this be voted upon right after the RMs have taken a
> decision? Anything blocking missing?
>  - Is the reference issue reported by Nicolas a blocker? Nicolas, can you
> clarify here?
>

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 that if it happens
:) )

But technically, it feels almost ready.

The reference issue looks "easy" to fix(esp. when its not me doing it yes
;) ). It'd be better to have it at the same time, but I can wait the next
version as I don't want to be the one with a blocker here, and also because
I can write a "degraded mode" for now if that's the plan.

Nicolas

Re: [PHP-DEV] Introspection for references

[Nicolas Grekas]

>
> 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 this. The
> only thing that comes to mind is comparing arrays by identity. E.g.
> https://github.com/symfony/symfony/blob/master/src/
> Symfony/Component/VarDumper/Cloner/VarCloner.php#L153 could check
> directly check whether an array is the $GLOBALS array. It would also allow
> direct recursion detection on arrays (ref https://stackoverflow.com/
> questions/9105816/is-there-a-way-to-detect-circular-arrays-in-pure-php).
> Doing the same on just references is nearly the same, but doesn't handle
> the $GLOBALS case correctly.
>

Note that AFAIK, not only $GLOBALS has a special behavior, but also any
"scope" array (the deprecated $context argument of error handlers at least,
maybe what get_defined_vars() also?

If we can return this info, I would definitely leverage it.
If not, that's no blocker, I'll let you decide.



> There is a 4th possibility: have a "ReflectionReference::getHash" method,
>> that would return a unique string/id per reference (what
>> symfony_zval_debug() does.)
>>
>
> Is this the same as my 3rd suggestion with a different name
>

No, it's the same, I read too fast.



> we could return the address hashed with a per-process key. This would make
> the function somewhat slower though.
>

That's exactly what we do in our extension, inspired by spl_object_hash().
On the perf side, a XOR should be OK :)

Thanks,
Nicolas

RE: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Zeev Suraski]

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 force words into 
your mouth.

Zeev

-Original Message-
From: Zeev Suraski [mailto:vsura...@gmail.com] 
Sent: Tuesday, July 10, 2018 11:05 AM
To: Nikita Popov 
Cc: Sara Golemon ; Christoph M. Becker ; 
Kalle Sommer Nielsen ; Internals 
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

Thanks for choosing not to push it for 7.3.

Re: [PHP-DEV] libmbfl API changes in PHP 7.3

[Nikita Popov]

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:
> https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b
> 39ca5cfa25
>
> To be specific:
> https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b
> 39ca5cfa25#diff-929fd74a8732776fa8776939a9b907d4L71
>
> It broke the code of the mailparse extension at this line:
> https://github.com/php/pecl-mail-mailparse/blob/master/
> php_mailparse_mime.c#L910
>
> Shouldn't the be documented? And/or is there an easy fix?
>

Thanks for pointing this out, this should be added to UPGRADING.INTERNALS.
mbstring and libmbfl underwent some larger refactorings in PHP 7.3, to make
its performance less abysmally bad.

The change you are running into is that many APIs have changed from working
with enum mbfl_no_encoding to const mbfl_encoding *. You will have to
mirror these changes: For example, instead of passing mbfl_no_encoding_8bit
to a function, you use _encoding_8bit. Instead of calling
mbfl_name2no_encoding(part->content_transfer_encoding) you instead use
mbfl_name2encoding(part->content_transfer_encoding) and so on.

Nikita

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Christoph M. Becker]

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 master branch almost a year
> ago, at the time PHP 7.2.0 Beta 1 was released. Weird moment for a BC
> break.

It seems to me that is actually the best time regarding our release
cycle: pushing breaking changes to *master* as early as possible after a
release branch has been forked, so there would still be time to revert
or to cater to related issues.

-- 
Christoph M. Becker

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

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Christoph M. Becker]

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:
> https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25
> 
> To be specific:
> https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25#diff-929fd74a8732776fa8776939a9b907d4L71
> 
> It broke the code of the mailparse extension at this line:
> https://github.com/php/pecl-mail-mailparse/blob/master/php_mailparse_mime.c#L910
> 
> Shouldn't the be documented? And/or is there an easy fix?

Have you tried to convert the first two arguments via mbfl_no2encoding()[1]?

Anyhow, it seems to me that we should document why “--with-libmbfl is no
longer available” (UPGRADING); because the bundled libmfl is now
mandatory, since it has been changed, and at least to superficially add
some respective notes to UPGRADING.INTERNALS.

[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] [VOTE] User-defined object comparison

[Marco Pivetta]

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 suggested approach is to add more interface-less reserved/magic
methods: an `Eq` and an `Ord` class would have solved this much more
elegantly and with clear type declarations that can be re-used in userland.
With this patch, we have to rely on `method_exists()` instead.
 4. It would also be much clearer to enforce that `Ord extends Eq`, rather
than adding implicit "sorting implies equality" rules
 5. "the methods are not restricted to instances of the same class" - this
is something I disagree with, but we lack the type system facilities to
declare the variance of the `Eq` and `Ord` operations for a specific class.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Mon, Jul 9, 2018 at 8:57 PM, Rudolf Theunissen <
rudolf.theunis...@gmail.com> wrote:

> 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 <
> rudolf.theunis...@gmail.com>
> wrote:
>
> > 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
> >  (June 21)
> >   - https://externals.io/message/102473 (June 26)
> >
> > The vote will be open until 2018-07-16.
> >
> > Thank you,
> > Rudi
> >
> >
>

Re: [PHP-DEV] [RFC] Typed Properties

[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 userland perspective it is safe for
inclusion. If you don't have confidence in something related to it, please
write a test case and help out.
 - can we get a yes/no from the RMs on whether we'll have the time window
to (potentially) get this voted and (*if* passed) merged? Shoot out a mail
with the decision, please. We could have a vote for which version to
include this in, if that's really such a big issue.
 - can we split out discussions on 8.0 scope? Minor versions are indeed for
features. If PHP 8.0 lacks interesting/marketing features, that's a
different story.
 - Nikita/Bob: can this be voted upon right after the RMs have taken a
decision? Anything blocking missing?
 - Is the reference issue reported by Nicolas a blocker? Nicolas, can you
clarify here?




Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Tue, Jul 10, 2018 at 7:24 AM, André Rømcke  wrote:

> 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 ;
> >> Stanislav Malyshev ; Marco Pivetta
> >> ; PHP internals 
> >> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> >>
> >> Just want to be annoying about this since the currently scheduled fork
> date for
> >> PHP-7.3 is 11 days off.
> >> 1/ Do we have *ANY* objections to additional alpha(s) to accommodate
> Typed
> >> Props? (I would propose two additional alphas) 2/ Do we actually need
> to hold a
> >> formal vote? (If so, that vote should start *now*)
> >
> > Sara,
> >
> > I do see a couple of issues here.
> >
> > First, it may be a personal thing, but I feel that the flexibility
> towards adding this is very contrasty with the inflexibility shown as we
> headed towards the PHP 7.0 feature freeze - inflexibility that resulted in
> a rushed (and IMHO wrong) decision regarding how to implement the
> non-strict types.  For the record - as I said back then - I think that the
> right way is to be flexible - the dates are just dates, and are - in all
> honesty - not that important - it’s the severe inconsistency that bothers
> me.
>
>
> Regardless of typed properties this sounds like something that should be
> tackled as an independent topic. (It could in theory, if accepted, be a new
> type flag introduced in 7.4 and made default in 8.0 that affect all type
> usage consistently.)
>
>
> >
> > Secondly, and somewhat related - typed properties isn't a small
> feature.  It is, in fact, a pretty huge one.  Making exceptions for a
> fairly minor feature or some extra deprecation is one thing.  Making an
> exception for something as fundamental as that feels wrong.
> >
> > Even though Nikita's proposal and implementation look pretty solid,
> something as fundamental as that should go through a substantial active
> discussion period (which didn't really happen here as it wasn't clear
> whether this was headed for an exceptional 7.3 addition or not) - and
> independently - should perhaps go hand-in-hand with fixing the flaws of the
> non-strict types - something we can do in PHP 8.  If we do the latter, then
> perhaps, just perhaps, we can introduce it hand-in-hand with typed
> variables - and if we do, it will be sensible to do it at the same time and
> not in a gradual rollout.  Personally, I think even independently of typed
> variables, typed properties feel like an 8.0 feature, not a 7.x feature.
>
>
> While I agree this is big, (from user land it’s fantastic), and should
> only go in if solid. It does contradict your argument the other day about
> being careful what to push into 8.0 scope as core resources are scarce.
>
> So if we look at it from that perspective, then spreading the risk is
> essentially safer.
>
>

Re: [PHP-DEV] Unifying logical operators

[Rowan Collins]

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 difference in
precedence, because without it, you could only use this idiom after
carefully checking that the left-hand side would be evaluated in one go,
and probably using an extra set of parentheses.


> ($gdImage = @imagecreatetruecolor(120, 20)) || die('Cannot Initialize new
GD image stream');

This is less readable both because of the extra parentheses, and because
the || operator is not as easily read as the English word "or".

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).

IF there is sufficient harm in having the extra operators, I would say
removal is the only option - making them behave as aliases for || etc would
just lead to even more confusion when they *don't* work the same way as in
Perl, and in earlier versions of PHP. I'm not 100% convinced by the harm,
though.


Finally, a note on the "xor" operator - your draft says that this is
equivalent to "!=", but that is not the case, because both can operate on
non-boolean values. Consider "1 != 2" (true) vs "1 xor 2" (false). I don't
think I've ever had a use for logical xor in PHP code, but there isn't
anything to confuse it with, so no reason to remove it.

Regards,
-- 
Rowan Collins
[IMSoP]

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

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 Beta 1 was released. Weird moment for a BC
break.
-- 
Jan

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

[PHP-DEV] libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

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:
https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25#diff-929fd74a8732776fa8776939a9b907d4L71

It broke the code of the mailparse extension at this line:
https://github.com/php/pecl-mail-mailparse/blob/master/php_mailparse_mime.c#L910

Shouldn't the be documented? And/or is there an easy fix?
-- 
Jan

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

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Zeev Suraski]

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. Becker 
>> > Cc: Nikita Popov ; Kalle Sommer Nielsen
>> > ; Internals 
>> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
>> >
>> > 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 clarify, it's ultimately an RM decision, but it should be guided by
>> the larger
>> > internals@ group.
>> >
>> > The way I read Zeev's objection is that it's primarily against TP, and
>> not against
>> > pushing out the FF per se.  I would recommend (in a non-RM, unofficial
>> capacity)
>> > pushing out the FF (not necessarily GA, but we can make that decision
>> later).  If
>> > these last minute things pass, they go in.  If they fail, then all
>> we've done is
>> > burned a month.
>>
>> It's a bit of both really.
>>
>> I hope that with all things considered (the little time we have left, the
>> little concrete discussion that happened so far as a result, the
>> inconsistency of allowing such a vote to push out feature freeze, the scope
>> of this feature being a lot more suitable for a major release, and our
>> inability to fix/improve other related elements at the same time) - Nikita
>> will propose this for 8.0 instead of 7.x.
>>
>
> 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 also on behalf of the wider PHP community,
> that we are not willing to sit on this feature for 2.5~3 years until a
> hypothetical PHP 8, even though it is essentially ready *now*. Of course,
> this is not my decision to make, but as Sara put it, that's the writing on
> 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 and no
> carrot.)
>

Thanks for choosing not to push it for 7.3.  At the same time - I think the
push for inclusion in 7.4 will be regrettable.   Other parts of what I'd
like to see in PHP 8 is, in fact, ready and can theoretically become a part
of PHP 7.4 (even JIT, potentially).  The reason we're doing it is twofold -
one, that's the expectation around major releases - that they will come
with major new features;  And two, perhaps more importantly - is that big
features sweeten the deal associated with migrating to a new major
versions, with the incompatibilities introduced and the code audits
required.  I obviously know it's extremely difficult to sit on new working
code for prolonged periods of time - but it can very much be the right
thing to do.  We did exactly that with the phpng codebase (which introduced
virtually zero incompatibilities, and could in theory be included in PHP
5.7), and we're likely going to do that again with JIT and FFI.   Either
way, I'll state my case when the discussion becomes relevant again.

In the PHP 8 RFC that I'm hoping to begin drafting in the near future, my
goal is to present 7.4 as a 'deprecation mostly' version, which while it
won't be forbidden to include new functionality in it, it will be
discouraged (with probably no 'teeth' to this discouragement, i.e. a
successful vote would still land a new feature into 7.4).

Zeev

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Nikita Popov]

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
> > ; Internals 
> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
> >
> > 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 clarify, it's ultimately an RM decision, but it should be guided by
> the larger
> > internals@ group.
> >
> > The way I read Zeev's objection is that it's primarily against TP, and
> not against
> > pushing out the FF per se.  I would recommend (in a non-RM, unofficial
> capacity)
> > pushing out the FF (not necessarily GA, but we can make that decision
> later).  If
> > these last minute things pass, they go in.  If they fail, then all we've
> done is
> > burned a month.
>
> It's a bit of both really.
>
> I hope that with all things considered (the little time we have left, the
> little concrete discussion that happened so far as a result, the
> inconsistency of allowing such a vote to push out feature freeze, the scope
> of this feature being a lot more suitable for a major release, and our
> inability to fix/improve other related elements at the same time) - Nikita
> will propose this for 8.0 instead of 7.x.
>

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 also on behalf of the wider PHP community,
that we are not willing to sit on this feature for 2.5~3 years until a
hypothetical PHP 8, even though it is essentially ready *now*. Of course,
this is not my decision to make, but as Sara put it, that's the writing on
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 and no
carrot.)

Finally, given the current situation where we have a whopping five (!!)
RFCs with votes ending the day before feature freeze, I'd say postponing
the schedule is a good idea even without any consideration to typed
properties. Just landing something like the comparison overloading RFC on
the day of feature freeze is not going to be pretty. We are quite obviously
rushing things right now, and I don't think keeping to some otherwise
arbitrary date is worth that.

Regards,
Nikita

Re: [PHP-DEV] Unifying logical operators

[Walter Parker]

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), and
> T_LOGICAL_XOR (xor) tokens, or aliasing them to ||, &&, and !=
> respectively.
>
> The behaviours of the two sets of logical operators are very similar (it's
> incredibly unclear how $x or $y would differ from $x||$y).  They perform
> almost identically except for the fact that the former set has a precedence
> lower that the assignment, null coalescing, and ternary operators[1].  The
> page on logical operators[2] states that the reason the two variations
> exist is that they "operate at different precedences" (which isn't a reason
> for existence, but rather a statement of differences).
>
> Example #1 on the logical operators page[2] gives an example of this
> difference:
> $e = false || true; // true
> $f = false or true; // false
>
> Because of the difference of precedence, the second line is evaluated as
> ($f = false) or true;
>
> In my mind (and in the mind of every programmer I've spoken to about this),
> this violates the principle of least astonishment[3].  The assignment
> operator is usually thought to be the lowest level of precedence other than
> parenthesis (as a typical statement would be "do some thing, then assign
> its value to this varible").
>
> This[4] stackoverflow question sheds some light on the intent of the
> alternative operators - they are used for "control flow" in the style of
> Ruby's "unless" operator[5]:
>
> 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.
>
> The only difference between the two (unless there are interactions I'm not
> aware of with the ternary or null coalescing operator) is the precedence
> with the assignment operator, causing the return value to be assigned
> without respect to the conditional.  I ran a quick (possibly imperfect)
> script on GitHub's top 30 repositories, and of the usages of the
> T_LOGICAL_* operators all but this one[6] operated equivalently to the
> symbolic ones:
> $gdImage = @imagecreatetruecolor(120, 20) or die('Cannot Initialize new GD
> image stream');
>
> In this case, the result of imagecreatetruecolor is intended to be placed
> in $gdImage, or if it is falsey, die with an error.  This could be
> rewritten as:
> ($gdImage = @imagecreatetruecolor(120, 20)) || die('Cannot Initialize new
> GD image stream');
>
> Or, in my opinion, more cleanly:
> $gdImage = @imagecreatetruecolor(120, 20);
> if(!$gdImage) die('Cannot Initialize new GD image stream');
>

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 one way to do any one task. Perl style is there’s more than one
way to do it.

PHP has been a mix of these styles.

The big question I have is how much PHP code will break due to an enforced
style requirement?

Removing them for style seems like it would be a big BC break. Aliasing
them might lead to more subtle bugs in legacy code.

>
> I've written a very rough draft RFC here[7] - and I would love feedback.
> If it's taken well I can put it up on the wiki.
>
> Thanks,
> Ryan "Iggy" Volz
>
> [1]: http://php.net/manual/en/language.operators.precedence.php
> [2]: http://php.net/manual/en/language.operators.logical.php
> [3]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> [4]: https://stackoverflow.com/a/5998351
> [5]:
>
> https://www.tutorialspoint.com/ruby/ruby_if_else.htm#Ruby%20unless%20modifier
> [6]:
>
> https://github.com/PHPOffice/PhpSpreadsheet/blob/aa5b0d0236c907fd8dba0883f3ceb97cc52e46ec/samples/Basic/25_In_memory_image.php#L24
> - likely copied from
> http://php.net/manual/en/function.imagecreatetruecolor.php
> [7]: https://github.com/iggyvolz/Unifying-Operators-RFC
>
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

RE: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Zeev Suraski]

> -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 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 clarify, it's ultimately an RM decision, but it should be guided by the 
> larger
> internals@ group.
> 
> The way I read Zeev's objection is that it's primarily against TP, and not 
> against
> pushing out the FF per se.  I would recommend (in a non-RM, unofficial 
> capacity)
> pushing out the FF (not necessarily GA, but we can make that decision later). 
>  If
> these last minute things pass, they go in.  If they fail, then all we've done 
> is
> burned a month.

It's a bit of both really.

I hope that with all things considered (the little time we have left, the 
little concrete discussion that happened so far as a result, the inconsistency 
of allowing such a vote to push out feature freeze, the scope of this feature 
being a lot more suitable for a major release, and our inability to fix/improve 
other related elements at the same time) - Nikita will propose this for 8.0 
instead of 7.x.

Zeev



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