[PHP-DEV] Re: Fwd: Intended proposal for class visibility

[Mark Randall]

On 26/03/2020 23:47, Javier Spagnoletti wrote:

Hey there!
I'm thrilled since this is my first proposal.


This idea has been discussed a great many times over the years, and has 
generally always been rejected during discussion as something that does 
not add value to the language.


If annotations RFC gets passed, there will likely be a suggested 
annotation for marking things as intentional, but I would assume it 
would carry no runtime effect.


Mark Randall

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Stanislav Malyshev]

Hi!

> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion

I like this shortcut. I am not sure though I understand why callable is
not allowed? Can't it just create a non-typed property?

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

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

[PHP-DEV] Fwd: Intended proposal for class visibility

[Javier Spagnoletti]

Hey there!
I'm thrilled since this is my first proposal.

I'd like to propose a new visibility schema for classes, based on a explicit
group of namespaces allowed to use the class.
The goal of this proposal is to provide a way to cover from a native
language feature what currently is usually patched using "@internal"
annotations.
If the visibility declaration ("internals" in this example) is present, the
class could only be visible for other classes on the list of the specified
namespaces.

Re: [PHP-DEV] [VOTE] Server-Side Request and Response Objects (v2)

[Pedro Magalhães]

Hi,

To justify my "no" vote. I agree that it would be nice if PHP would provide
these objects out of the box, but there are some inconsistencies in the
object properties that made me oppose this. For instance, not all headers
are treated equally, while some become properties of the request object,
others must be accessed in the headers array. And the line that divides
them seems a bit arbitrary. For instance, CONTENT_MD5 gets special
treatment in this object while it was never special in the $_SERVER
superglobal. Some other values are missing like REQUEST_TIME (it's missing
at least from the proposal and the linked README). Finally, making
decisions like overwriting method if a HTTP_X_HTTP_METHOD_OVERRIDE header
is present seem too opinionated for an object that should be more agnostic.
It does make sense, but it hides away information from the user in an
attempt to be helpful.

In conclusion, I do think PHP should offer an OOP oriented way to deal with
requests and responses, but those objects should be more consistent and
less opinionated.

Regards,
Pedro

Re: [PHP-DEV] semicolon terminator for switch cases

[Christoph M. Becker]

On 26.03.2020 at 23:04, Claude Pache wrote:

>> Le 26 mars 2020 à 19:37, Ilija Tovilo  a écrit :
>>
>> What's the reasoning behind this? I find it weird an inconsistent.
>
> This is a manifestly a leftover of an old syntax. Take a look at the PHP/FI 2 
> manual:
>
> Language constructs:
> https://www.php.net/manual/phpfi2.php#lang 
> 
>
>
> ```
>if($a==5 &&  $b!=0 );
> $c = 100 + $a / $b;
>   endif;
> >
> ```
>
> and, in particular, switch construct:
> https://www.php.net/manual/phpfi2.php#switch 
> 
>
> ```
>  $a=0;
>   switch($a) {
> case 1;
>   echo "a is 1";
>   break;
> case "hello";
>   echo "a is hello";
>   break;
> default;
>   echo "a is unknown";
>   break;
>   }
> >
> ```
>
> Note that every line of code, including `if (...);` and `case...;`, is 
> consistently terminated by a semicolon.
>
> In a subsequent major version, the syntax was modified, and you would use a 
> colon instead of a semicolon in a number of places, as you can write today:
>
> ```
>if ($a==5 &&  $b!=0):
> $c = 100 + $a / $b;
>   endif;
> >
> ```
>
> Although the old `if (true);` syntax has been removed (probably because of 
> ambiguity or difficulty of parsing), the old `case 1;` syntax could be left 
> without issue.

Interesting!  Thanks for digging this out. :)

--
Christoph M. Becker

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

[PHP-DEV] Re: semicolon terminator for switch cases

[Andrea Faulds]

Hi Ilija,

Ilija Tovilo wrote:

Looking through the language grammer I discovered that switch cases can also be 
terminated with a `;` instead of a `:`.

```
switch ($i) {
 case 1;
 return 1;
 default;
 return 2;
}
```

https://3v4l.org/o7nD8

This is in fact documented:
https://www.php.net/manual/en/control-structures.switch.php

What's the reasoning behind this? I find it weird an inconsistent.


For whatever reason, I somehow remember that this dates to at least 
PHP/FI 2.0, which means it's as least as old as me (24 years… no, I was 
not involved with PHP back then ;). And indeed, the case statement is 
mentioned in the manual (https://www.php.net/manual/phpfi2.php#lang), 
with an example to be found in 
https://museum.php.net/php2/php-2.0.tar.gz under php-2.0/test/lang/003.tst:


--TEST--
Simple Switch Test...
--POST--
--GET--
--FILE--

--EXPECT--
Content-type: text/html
good

Being able to use a colon instead of a semicolon here is, I guess, a 
more modern thing. Was it PHP 3 or PHP 4 that changed this? Who knows.


I don't think it's hurting anyone as it is… can we leave it in peace? :)

Thanks,
Andrea

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

Re: [PHP-DEV] semicolon terminator for switch cases

[Claude Pache]

> Le 26 mars 2020 à 19:37, Ilija Tovilo  a écrit :
> 
> What's the reasoning behind this? I find it weird an inconsistent.
> 

This is a manifestly a leftover of an old syntax. Take a look at the PHP/FI 2 
manual:

Language constructs:
https://www.php.net/manual/phpfi2.php#lang 



```

```

and, in particular, switch construct:
https://www.php.net/manual/phpfi2.php#switch 


```
  
```

Note that every line of code, including `if (...);` and `case...;`, is 
consistently terminated by a semicolon.

In a subsequent major version, the syntax was modified, and you would use a 
colon instead of a semicolon in a number of places, as you can write today:

```

```

Although the old `if (true);` syntax has been removed (probably because of 
ambiguity or difficulty of parsing), the old `case 1;` syntax could be left 
without issue.

—Claude

Re: [PHP-DEV] semicolon terminator for switch cases

[Claude Pache]

> Le 26 mars 2020 à 21:49, Benoit SCHILDKNECHT  a écrit :
> 
> A semi-colon is terminal. Italways is. "You see this set of instructions? 
> Done.". But in this case, itis not. You see the problem?
> 

No I don’t see the problem. Inside  a switch construct, when you reach the end 
of an instruction (or of a set of instructions) that is not (resp. does not end 
with) a control-flow statement, you pass to the next one. I’m sure that 
everybody knows that you have to use an explicit control-flow statement like 
“break” or “return” if you want to be “done” before reaching the bottom of the 
switch construct.

Or maybe people could misguess that “;” in that context is an odd way to mean 
“: break;”? 

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

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Ben Ramsey]

> On Mar 26, 2020, at 13:52, Nikita Popov  wrote:
> 
> Hi internals,
> 
> This has been declined in the past, but I just keep making this mistake,
> and believe it deserves reconsideration...
> 
> https://wiki.php.net/rfc/trailing_comma_in_parameter_list
> 
> Nikita


Yes, please

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Larry Garfield]

On Thu, Mar 26, 2020, at 1:52 PM, Nikita Popov wrote:
> Hi internals,
> 
> This has been declined in the past, but I just keep making this mistake,
> and believe it deserves reconsideration...
> 
> https://wiki.php.net/rfc/trailing_comma_in_parameter_list
> 
> Nikita

Endorse.

I don't think there's anything more to add, just "endorse".

--Larry Garfield

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

Re: [PHP-DEV] semicolon terminator for switch cases

[Benoit SCHILDKNECHT]

Le Thu, 26 Mar 2020 21:28:38 +0100, Stanislav Malyshev
 a écrit:


Hi!

On 3/26/20 1:26 PM, David Rodrigues wrote:

I agree with Tovilo. It is weird and confusing. Actually I never know
that it was possible.


You seem to contradict yourself - if you never knew it was possible, how
could you ever be confused by it?



OK, I'm often lurking, but I have to react to this. I never knew it was
possible too, but I am also confused by this. A semi-colon is terminal. It 
always is. "You see this set of instructions? Done.". But in this case, it 
is not. You see the problem?


--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [PHP-DEV] semicolon terminator for switch cases

[Stanislav Malyshev]

Hi!

On 3/26/20 1:26 PM, David Rodrigues wrote:
> I agree with Tovilo. It is weird and confusing. Actually I never know
> that it was possible. 

You seem to contradict yourself - if you never knew it was possible, how
could you ever be confused by 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] semicolon terminator for switch cases

[David Rodrigues]

I agree with Tovilo. It is weird and confusing. Actually I never know that
it was possible. And the ";" sounds like "it ends here", while ":" counds
like "it does it ->". For me, "case 1;" will sounds like "skip case 1".


Atenciosamente,
David Rodrigues


Em qui., 26 de mar. de 2020 às 17:14, Stanislav Malyshev <
smalys...@gmail.com> escreveu:

> Hi!
>
> > Maybe something to deprecate in PHP 8.0.
> > https://wiki.php.net/rfc/deprecations_php_8_0
>
> Why? Whose life it'd make easier?
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] semicolon terminator for switch cases

[Stanislav Malyshev]

Hi!

> Maybe something to deprecate in PHP 8.0.
> https://wiki.php.net/rfc/deprecations_php_8_0

Why? Whose life it'd make easier?

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

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

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Matthew Brown]

I accept that it adds an extra level of understanding to the language – if
you see

function addAmounts($a, $b) { return $a + $b; }

you no longer definitely know the answer will be numeric.

However, I imagine that the sorts of people who will use this are _also_
the sorts of people who would add type annotations clearly – so you'd much
more likely see

function addAmounts(CurrencyAmount $a, CurrencyAmount $b) { return $a + $b;
}

where it's trivial to understand that there's userspace operator
overloading going on.

On Tue, 24 Mar 2020 at 06:04, Marco Pivetta  wrote:

> Hey Jan,
>
> Just posting here why I voted "no": it is not your implementation proposal,
> but rather the concept per-se that IMO shouldn't land in the language.
>
> Operator overloading makes call-site code reading extremely hard, and it
> makes the language much more complex for very little benefit.
>
> Everything suggested in the RFC can be done by using explicit arrows: `->`
> (method calls), which lead to expressively named methods and parameters.
>
> I have posted similar thoughts about `->__toString()` and `->toString()`
> when it comes to cast operations vs explicit calls at
>
> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
>
> Overall, without type classes and infix functions, operator overloading is,
> IMO, just messy.
>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Mon, Mar 23, 2020 at 6:58 PM  wrote:
>
> > Hi internals,
> >
> > I have opened voting on
> > https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> > users
> > to overload operators in their own classes.
> >
> > Voting closes on 2020-04-06.
> >
> > Regards,
> > Jan Böhmer
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

$handle = fopen('test.csv', 'r');
while (($data = fgetcsv($handle)) !== false) {
  [int $id, string $data, int $year] = $data;
  // do something with the correctly typed variables
}

The code would trigger a fatal error when strict_types are enabled. With
strict_types disabled it would behave identically as the currently
proposed casts.



As I mentioned in a previous e-mail, if it followed current strict_types=0
semantics, it would error if the input row was something like
"42,hello,not-a-valid-year".

Following standard cast semantics, that input would instead silently give
you a value of 0 in $year, which is often not what you want.



Hi Rowan,

I liked your idea of strict casts which would increase the possibilities
of casting in general but also improve casting while array destructuring.

Let's have a look at various combinations.

The current proposal (behaviour doesn't depend on strict_types):

[(int) $id, (string) $data, (int) $year] = $data;

"42,hello,2020" --> Works as expected, everything fine
"42,hello,not-a-valid-year" --> results silently in a 0. May not be
wanted, as you describe, but in my opinion that's fine as it's the
current casting behaviour


Extending the proposal with strict castings (behaviour doesn't depend on
strict_types):

[(!int) $id, (!string) $data, (!int) $year] = $data;

"42,hello,2020" --> Works as expected, everything fine as "2020" can be
casted to an int
"42,hello,not-a-valid-year" --> Results in a TypeError as the year can't
be casted to an int


Using regular type checks (depends on strict_typed):

declare(strict_types=0);
[int $id, string $data, int $year] = $data;

"42,hello,2020" --> Works as expected, everything fine as the id with
"42" and the year with "2020" can be casted to an int
"42,hello,not-a-valid-year" --> Results in a TypeError as the year can't
be casted to an int


declare(strict_types=1);
[int $id, string $data, int $year] = $data;

"42,hello,2020" --> Results in a TypeError as id and year are both strings
"42,hello,not-a-valid-year" --> Results in a TypeError as id and year
are both strings

My favourite behaviour would be the one described for strict
castings/regular type checks with strict_types disabled. But I don't
like the idea it's only usable without strict_types to get the
casting-feature intended by the RFC.

Cheers, Enno

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

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Lynn]

On Thu, Mar 26, 2020 at 7:52 PM Nikita Popov  wrote:

> Hi internals,
>
> This has been declined in the past, but I just keep making this mistake,
> and believe it deserves reconsideration...
>
> https://wiki.php.net/rfc/trailing_comma_in_parameter_list
>
> Nikita
>

This would be a great addition, my "duplicate line" thanks you! (and so I)

Regards,
Lynn

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Michał Brzuchalski]

pon., 23 mar 2020 o 18:58  napisał(a):

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>

I got two comments, a little late but always better than even later.

The first thing is for operator methods when the operation is not supported
I would see simply `return null;` as the right solution
instead of constant, which name no one will remember.

The second thing is notices which are confusing when suggesting to go
and implement overloaded operator method on extension derived classes
like stdClass like below:

Notice: You have to implement the __add function in class stdClass to use
this operator with an object in...

The text of the notice is not documented in the RFC but it is implemented
that way in the patch.
A PHP developer is not likely gonna download the php-src source code,
build environment and go with the ext/standard implementation and start
adding it in C.
The notice in this cases should either be different or not emitted at all.
If the latter then that has to be documented I guess.

Cheers,
--
Michał Brzuchalski

[PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Nikita Popov]

Hi internals,

This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...

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

Nikita

[PHP-DEV] semicolon terminator for switch cases

[Ilija Tovilo]

Hi internals

Looking through the language grammer I discovered that switch cases can also be 
terminated with a `;` instead of a `:`.

```
switch ($i) {
case 1; 
return 1;
default; 
return 2;
}
```

https://3v4l.org/o7nD8

This is in fact documented:
https://www.php.net/manual/en/control-structures.switch.php

What's the reasoning behind this? I find it weird an inconsistent.

Maybe something to deprecate in PHP 8.0.
https://wiki.php.net/rfc/deprecations_php_8_0

Regards

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

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Derick Rethans]

On Thu, 26 Mar 2020, Derick Rethans wrote:

> On Mon, 23 Mar 2020, jan.h.boeh...@gmx.de wrote:
> 
> > I have opened voting on
> > https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> > to overload operators in their own classes.
> 
> I've always been a strong proponent of operator overloading, but as PHP 
^
 I meant "opponent" there of course.
> already has it internally, it makes sense to also make that information 
> available for userland.

In any case, I am a +1!

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Nikita Popov]

On Thu, Mar 26, 2020 at 5:02 PM David Rodrigues 
wrote:

> Hello!
>
> With all respect, seems a bit confuses to me, without in fact offer a new
> feature, just a shortcut. I hope it's me seeing it the wrong way.
>
> What happen if I rename the constructor parameters on a child class
> constructor?
>
> Example (https://3v4l.org/VqQde):
>
> class A {
> public function __construct(public int $x) { ... }
> }
>
> class B extends A {
> public function __construct(public int $y) { ...;
> parent::__construct($y); }
> }
>

Constructors (in general, independent of this feature) are per-class and do
not participate in classical signature-based inheritance (the exception
being abstract constructors, but those aren't relevant here). The notion of
"renaming" a constructor parameter doesn't make sense in that regard,
because the parameters of the child constructor have absolutely no relation
to the parameters of the parent constructor.

The way to write your example would be:

class A {
public function __construct(public int $x) {}
}

class B extends A {
public function __construct(int $x) {
parent::__construct($x);
// Your extra logic here.
}
}

Regards,
Nikita

RE: [PHP-DEV] Re: [VOTE] Userspace operator overloading

[jan.h.boehmer]

On Thursday, March 26, 2020 6:19 PM Guilliam Xavier  
wrote:

>> If the concat operator is not overloaded, the behavior is like now, and the 
>> objects are converted implicitly to strings (so $a . $b actually means 
>> (string) $a . (string) $b).
>> Furthermore an notice is triggered, hinting the user that he could overload 
>> the concat operator. (Maybe here a different message than for the other 
>> operators would be useful).
>
> I fear that "hint" notice could break Symfony apps... Couldn't you just not 
> trigger it in this case?

Yes this would be possible and I think that it might be reasonable to omit the 
notice in this case (maybe only if the objects really implement a __toString).
What do others think about this?

Regards,
Jan

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

Re: [PHP-DEV] Re: [VOTE] Userspace operator overloading

[Christoph M. Becker]

On 26.03.2020 at 18:18, Guilliam Xavier wrote:

> On Thu, Mar 26, 2020 at 5:37 PM  wrote:
>>
>> The overloaded concat operator has higher priority than the __toString() 
>> method.
>> So if Class A overloades the concat operator, then calling $a . $b means 
>> ClassA::__concat($a, $b);  (Note that both operands are passed in their 
>> original form)
>> If you want to concat the string representations, you will have to 
>> explicitly convert the objects to strings:
>> $ret = (string) $a . (string) $b;
>
> This first part seems legit to me.
>
>> If the concat operator is not overloaded, the behavior is like now, and the 
>> objects are converted implicitly to strings (so $a . $b actually means 
>> (string) $a . (string) $b).
>> Furthermore an notice is triggered, hinting the user that he could overload 
>> the concat operator. (Maybe here a different message than for the other 
>> operators would be useful).
>
> I fear that "hint" notice could break Symfony apps... Couldn't you
> just not trigger it in this case?

Either that (it's what I would prefer), or clearly document that BC
break (even if it's just about a notice).

Thanks,
Christoph

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

Re: [PHP-DEV] Re: [VOTE] Userspace operator overloading

[Guilliam Xavier]

On Thu, Mar 26, 2020 at 5:37 PM  wrote:
>
> The overloaded concat operator has higher priority than the __toString() 
> method.
> So if Class A overloades the concat operator, then calling $a . $b means 
> ClassA::__concat($a, $b);  (Note that both operands are passed in their 
> original form)
> If you want to concat the string representations, you will have to explicitly 
> convert the objects to strings:
> $ret = (string) $a . (string) $b;

This first part seems legit to me.

> If the concat operator is not overloaded, the behavior is like now, and the 
> objects are converted implicitly to strings (so $a . $b actually means 
> (string) $a . (string) $b).
> Furthermore an notice is triggered, hinting the user that he could overload 
> the concat operator. (Maybe here a different message than for the other 
> operators would be useful).

I fear that "hint" notice could break Symfony apps... Couldn't you
just not trigger it in this case?

-- 
Guilliam Xavier

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Ben Ramsey]

> On Mar 26, 2020, at 08:30, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
> 
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some existing discussion on the
> topic can be found in that thread.
> 
> The primary motivation for this feature is to close the currently rather
> wide gap between the use of ad-hoc array structures, and the use of
> well-defined and type-safe value objects. The latter is what we want people
> to use, but the former is, unfortunately, what is *easy* to use.


Will this cause any problems with ReflectionClass? (I’m assuming not, but 
wanted to ask anyway.)

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Michał Brzuchalski]

czw., 26 mar 2020 o 14:31 Nikita Popov  napisał(a):

> Hi internals,
>
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some existing discussion on the
> topic can be found in that thread.
>
>
As I already said in linked topic. IMHO this is wrong and can be easily
overused.

A list of properties is changed into a list of constructor method arguments
which
can be easily overused on long argument lists and when the time comes to
have attributes then the list of promoted arguments with their annotations
and some extra blank lines then to improve readability could lead to
long constructor signature list on a different level of indentation which
also then always has to be un-collapsed in IDE and on the top of a class to
keep the track of properties where usually list of properties exists with
additional named constructors (always at the top).

Not even mentioning that mix of promoted and un-promoted argument list
would just feel awkward and that kind of mixed constructor where some of
arguments are assigned magically and some of them not can make it harder to
read.

And I'm not saying this cause I'm preparing another proposal for filling
the gap
between the use of ad-hoc array structures, and the use of well-defined and
type-safe value types.
I'm saying this because PHP was always verbose and easy to read/decipher
this solution IMHO has more drawbacks regarding readability than benefits.

Cheers,
--
Michał Brzuchalski

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Derick Rethans]

On Mon, 23 Mar 2020, jan.h.boeh...@gmx.de wrote:

> Hi internals,
> 
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> to overload operators in their own classes.

I've always been a strong proponent of operator overloading, but as PHP 
already has it internally, it makes sense to also make that information 
available for userland.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Sara Golemon]

On Thu, Mar 26, 2020 at 8:31 AM Nikita Popov  wrote:

> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some existing discussion on the
> topic can be found in that thread.
>
> Similar to an RFC you submitted six years ago:
https://wiki.php.net/rfc/automatic_property_initialization
I think the availability of typed properties makes the syntax for this much
more sensible and I look forward to +1ing it.

-Sara

RE: [PHP-DEV] Re: [VOTE] Userspace operator overloading

[jan.h.boehmer]

On Thursday, March 26, 2020 3:50 AM Jakob Givoni  wrote:

> On Wed, Mar 25, 2020 at 6:28 AM Christoph M. Becker  wrote:
>
>> It seems to me that the RFC is not sufficiently specific enough 
>> regarding the concatenation of instances of classes which implement 
>> __toString().
>
> Exactly what I was thinking too. Would be nice with some examples on this.

I am not sure if I can (or should) still add this to the RFC, here some 
clarification on this:

The overloaded concat operator has higher priority than the __toString() method.
So if Class A overloades the concat operator, then calling $a . $b means 
ClassA::__concat($a, $b);  (Note that both operands are passed in their 
original form)
If you want to concat the string representations, you will have to explicitly 
convert the objects to strings: 
$ret = (string) $a . (string) $b;

If the concat operator is not overloaded, the behavior is like now, and the 
objects are converted implicitly to strings (so $a . $b actually means (string) 
$a . (string) $b).
Furthermore an notice is triggered, hinting the user that he could overload the 
concat operator. (Maybe here a different message than for the other operators 
would be useful).

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Chase Peeler]

On Thu, Mar 26, 2020 at 9:33 AM Paul M. Jones  wrote:

>
>
> > On Mar 26, 2020, at 08:30, Nikita Popov  wrote:
> >
> > Hi internals,
> >
> > I would like to submit the following RFC for your consideration:
> > https://wiki.php.net/rfc/constructor_promotion
>
> Big fan. Thanks for this.
>
>
I like this too. One question (and apologies if I overlooked this in the
RFC), but is type-hinting required, or would the following be accepted:

class bar {
   public function __construct(public $foo){}
}


>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[David Rodrigues]

Hello!

With all respect, seems a bit confuses to me, without in fact offer a new
feature, just a shortcut. I hope it's me seeing it the wrong way.

What happen if I rename the constructor parameters on a child class
constructor?

Example (https://3v4l.org/VqQde):

class A {
public function __construct(public int $x) { ... }
}

class B extends A {
public function __construct(public int $y) { ...;
parent::__construct($y); }
}


Atenciosamente,
David Rodrigues


Em qui., 26 de mar. de 2020 às 12:45, Sebastian Bergmann 
escreveu:

> Am 26.03.2020 um 14:30 schrieb Nikita Popov:
> > I would like to submit the following RFC for your consideration:
> > https://wiki.php.net/rfc/constructor_promotion
>
> Looks good to me! Thanks.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Sebastian Bergmann]

Am 26.03.2020 um 14:30 schrieb Nikita Popov:

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion


Looks good to me! Thanks.

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Paul M. Jones]

> On Mar 26, 2020, at 08:30, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion

Big fan. Thanks for this.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

[PHP-DEV] [RFC] Constructor Property Promotion

[Nikita Popov]

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is *easy* to use.

Regards,
Nikita

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Rowan Tommins]

On Thu, 26 Mar 2020 at 12:39, Enno Woortmann  wrote:

>
> $handle = fopen('test.csv', 'r');
> while (($data = fgetcsv($handle)) !== false) {
>  [int $id, string $data, int $year] = $data;
>  // do something with the correctly typed variables
> }
>
> The code would trigger a fatal error when strict_types are enabled. With
> strict_types disabled it would behave identically as the currently
> proposed casts.
>


As I mentioned in a previous e-mail, if it followed current strict_types=0
semantics, it would error if the input row was something like
"42,hello,not-a-valid-year".

Following standard cast semantics, that input would instead silently give
you a value of 0 in $year, which is often not what you want.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

Hi Levi,

Am 25.03.2020 um 21:44 schrieb Levi Morrison:

To me, this is almost a good idea. However, I would want regular type
checking, not casts. Importantly, regular type checks would fit well
on allowing array destructuring directly in function signatures, which
would basically be a form of named parameters.



How exactly do you imagine array destructuring in function signatures
with type checks? Something like:

function test(['parameter1' => int $parameter1, 'parameter2' => string
$parameter2) {
    // ... do something with $parameter1 and $parameter2
}

Calling the function then may look like:

test(['parameter1' => 100, 'parameter2' => 'Hello World']);

I guess the type check then depends on the strict_types direcitve
whether a call like:

test(['parameter1' => 100, 'parameter2' => 100]);

would trigger a TypeError or be valid and cast the value for $parameter2
to a string just like a casual function signature with a string parameter.


The same behaviour would be applied to array destructuring outside of
function signatures. Assumed we gather data from a CSV file:

1,Test,2002
2,Example,2010
3,Demo,2016

And we want to process the data with array destructuring like:

$handle = fopen('test.csv', 'r');
while (($data = fgetcsv($handle)) !== false) {
    [int $id, string $data, int $year] = $data;
    // do something with the correctly typed variables
}

The code would trigger a fatal error when strict_types are enabled. With
strict_types disabled it would behave identically as the currently
proposed casts. I wouldn't want the example above to trigger a TypeError
even when strict_types are enabled. As a form of named parameters
regular type checks should definitely preferred over a cast but for the
current usage of array destructuring I think regular type checks cover
different use cases (which may also exist) than my proposal.

Enno

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

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

[Ilija Tovilo]

On 22.03.20, 18:17, "Dan Ackroyd"  wrote:

> $condition || throw new Exception('$condition must be truthy')
>   && $condition2 || throw new Exception('$condition2 must be truthy');
> 
> The "Deprecate left-associative ternary operator"* RFC made it so that
> parentheses are required when ternary operators are nested in
> complicated statements.
> 
> Would a similar requirement for parentheses around complicated throw
> expressions be a suitable solution to avoid people being surprised by
> the behaviour?

I've thought about this some more. There is a reasonable way to recognize this, 
namely to check if the expression after the throw keyword is of type 
ZEND_AST_OR or ZEND_AST_AND. The expression above will fail with this message 
(given that $condition is false):

```
Fatal error: Uncaught Error: Can only throw objects in ...
```

IMO this is clear enough that a message for this edge case is not necessary.

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

Re: [PHP-DEV] PHP 8.0 Release Manager Selection

[Jakub Zelenka]

Hi,

I think it might be worth to discuss if we want to go for PHP 8.0 at this
time. I'd think that lots of businesses will prefer stability over new
features and resolving BC breaks in the coming months. Also life of many
devs might get impacted. I'm thinking that it would be good to at least
consider if it makes sense to for example branch 7.5 from 7.4 and just
concentrate on stability and possibly additional deprecations. It would
also give us more time to improve 8.0 - at least I plan to do bunch of
things on openssl ext but the current situation makes it a bit harder for
me and I would imagine that it might be the case for others as well.

Cheers

Jakub

On Thu, Mar 26, 2020 at 11:12 AM Derick Rethans  wrote:

> Hi again,
>
> Just a reminder that if you're interested in being one of the PHP 8.0
> release managers, then now is the time to step forwards. I'll be
> starting the selection procedure next week.
>
> cheers,
> Derick
>
> On Thu, 19 Mar 2020, Derick Rethans wrote:
>
> > Hi all!
> >
> > With the first alpha of 8.0 due in three months, I think it's time to
> > start the process of finding and electing release managers for the next
> > release of PHP.
> >
> > We are looking for two developers to take on this role. Whomsoever is
> > elected will be guided and helped by the previous RMs and the excellent
> > documentation in php-src:README.RELEASE_PROCESS.
> >
> > Candidates should have a reasonable knowledge of internals (without
> > necessarily being a C guru), be confident about merging pull requests
> > without breaking backward compatibility, doing triage for bugs, liaising
> > with previous release managers, and generally getting the branch in good
> > shape, as these are among the activities you will be undertaking as
> > release manager.
> >
> > Please put your name forward here if you wish to be considered a
> > candidate. An initial TODO page has been added to the wiki and contains
> > provisional dates for GA and pre-releases:
> > https://wiki.php.net/todo/php80
> >
> > cheers,
> > Derick
> >
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] PHP 8.0 Release Manager Selection

[Gabriel Caruso]

Hello there,

I'd like to throw my name in the selection os RM for PHP 8 :)

I've been contributing to PHP itself for a while, apart from many other
contributions in the ecosystem.

Best regards,

Re: [PHP-DEV] PHP 8.0 Release Manager Selection

[Derick Rethans]

Hi again,

Just a reminder that if you're interested in being one of the PHP 8.0 
release managers, then now is the time to step forwards. I'll be 
starting the selection procedure next week.

cheers,
Derick

On Thu, 19 Mar 2020, Derick Rethans wrote:

> Hi all!
> 
> With the first alpha of 8.0 due in three months, I think it's time to 
> start the process of finding and electing release managers for the next 
> release of PHP.
> 
> We are looking for two developers to take on this role. Whomsoever is 
> elected will be guided and helped by the previous RMs and the excellent 
> documentation in php-src:README.RELEASE_PROCESS.
> 
> Candidates should have a reasonable knowledge of internals (without 
> necessarily being a C guru), be confident about merging pull requests 
> without breaking backward compatibility, doing triage for bugs, liaising 
> with previous release managers, and generally getting the branch in good 
> shape, as these are among the activities you will be undertaking as 
> release manager.
> 
> Please put your name forward here if you wish to be considered a
> candidate. An initial TODO page has been added to the wiki and contains
> provisional dates for GA and pre-releases:
> https://wiki.php.net/todo/php80
> 
> cheers,
> Derick
> 
> 

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast

[Máté Kocsis]

Hi Lynn,

Thank you very much for the input! Then we could add a secondary vote to
the RFC where an
upgrade path was decided upon.

The first such path is the one proposed by Christoph:
Introduce a temporary ini setting with which a "debug" mode of float to
string casting could be
enabled. That is, when it's turned on and a casting is affected by locale
settings then a warning
is emitted. This setting would be removed in a (near) future version of
PHP. Although
PHP 8.1 would be an unusual candidate to do so, but it *might* be possible
if we found a good
way to warn people from day 0 that it's just a temporary flag? Maybe by an
immediate deprecation?

Is there any other idea for a sensible upgrade path?

Cheers:
Máté

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

[Nikita Popov]

On Sun, Mar 22, 2020 at 5:17 PM Ilija Tovilo  wrote:

> Hi everybody! I hope you’re doing well.
>
>
>
> Due to the modest feedback I’d like to move the throw expression RFC to
> “under discussion”.
>
> https://wiki.php.net/rfc/throw_expression
>
>
>
> In short, the RFC proposes to convert the throw statement into an
> expression to make it usable in arrow functions, the coalesce operator, as
> well as the ternary/elvis operator.
>
> If you have any feedback, concerns, or if you want to express your
> interest or lack thereof, let me know!
>

Looks like a reasonable change to me. Maybe interesting to compare with the
ECMAScript and C# proposals you reference:

The ECMAScript proposal (https://tc39.es/proposal-throw-expressions/)
defines the throw expression as a very high precedence operator, rather
than a low precedence one. There's discussion on that in
https://github.com/tc39/proposal-throw-expressions/issues/10. Reading that
thread, it seems like nobody actually wants the high precedence version,
but there are some ECMAScript-specific issues with low precedence, because
of conflicts with comma expressions. Thankfully that doesn't apply to us.

The C# proposal (
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-7.0/throw-expression)
limits the use of throw expressions to specific context only (in short
lambdas and on the right hand side of ?: and ??). I'm personally not a fan
of that, unless there's a technical motivation for that. If it's just about
enforcing coding style, there's already plenty of weird expressions you can
write right now. I don't want to add special cases to the language
specification to enforce someone's style preferences.

> The "Deprecate left-associative ternary operator"* RFC made it so that
> parentheses are required when ternary operators are nested in
> complicated statements.

I should probably explicitly say here that the parentheses are required not
because I think it is a good idea to require them, but to avoid changing
the interpretation of an expression from one version to the next. Given
that we did end up changing the precedence of the "." operator (rather than
requiring parentheses), this choice is somewhat dubious now, and it would
have been better to simply change the interpretation of the ternary in PHP
8 as well.

Regards,
Nikita

Re: [PHP-DEV] RFC Raised for str_starts_with and str_ends_with

[Guilliam Xavier]

On Thu, Mar 26, 2020 at 9:54 AM Nikita Popov  wrote:
>
> On Thu, Mar 26, 2020 at 3:36 AM  wrote:
>
> > Hi,
> >
> > Hope everyone is doing alright. I just raised a new RFC
> > (https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions ,
> > github patch: https://github.com/php/php-src/pull/5300) for adding
> > str_starts_with and str_ends_with to PHP. I would like to open this RFC
> > up to discussion.
> >
> > I raised a similar RFC about 9 months ago
> > (https://wiki.php.net/rfc/add_str_begin_and_end_functions) that was
> > narrowly rejected. A major criticism of that RFC was the inclusion of
> > case-insensitive versions of str_starts_with and str_ends_with. I have
> > incorporated feedback from that experienced and narrowed the new RFC to
> > only propose str_starts_with and str_ends_with.
> >
>
> I was in favor of the previous RFC, so also in favor of this one :) These
> are going to complement the recently added str_contains() nicely.
>
> Notes on text:
>
> > After that RFC was closed, a code freeze was in place for PHP8's release.
> PHP8 has now been released and several individuals have requested the
> str_starts_with and str_ends_with functionality again. This is a simple but
> highly desired functionality for PHP.
>
> I think you mean PHP 7.4 here. PHP 8.0 is not yet released, and not in
> feature freeze either.
>
> > Add str_starts_with, and str_starts_with_ci() functions
>
> The second function should probably be str_ends_with() :)
>
> Nikita

Hi Will,

First, thank you for re-working on this, I would love to see it happen! :)

Nevertheless, apart from some typos (already reported), I still think
the RFC needs a "Motivation" section with actual examples of userland
implementations (using functions like
str[r]pos/strncmp/substr[_compare]... often with strlen, or even
preg_match/fnmatch... [with escaping]) and the downsides of each (e.g.
CPU-inefficient, memory-inefficient, error-prone, hard to
understand...) plus how they handle empty strings.

(And also probably shorten the introduction ^^ or move parts into a
new subsection)

PS: you could also add a link to the str_contains RFC

Best regards,

-- 
Guilliam Xavier

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

Re: [PHP-DEV] RFC Raised for str_starts_with and str_ends_with

[Nikita Popov]

On Thu, Mar 26, 2020 at 3:36 AM  wrote:

> Hi,
>
> Hope everyone is doing alright. I just raised a new RFC
> (https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions ,
> github patch: https://github.com/php/php-src/pull/5300) for adding
> str_starts_with and str_ends_with to PHP. I would like to open this RFC
> up to discussion.
>
> I raised a similar RFC about 9 months ago
> (https://wiki.php.net/rfc/add_str_begin_and_end_functions) that was
> narrowly rejected. A major criticism of that RFC was the inclusion of
> case-insensitive versions of str_starts_with and str_ends_with. I have
> incorporated feedback from that experienced and narrowed the new RFC to
> only propose str_starts_with and str_ends_with.
>

I was in favor of the previous RFC, so also in favor of this one :) These
are going to complement the recently added str_contains() nicely.

Notes on text:

> After that RFC was closed, a code freeze was in place for PHP8's release.
PHP8 has now been released and several individuals have requested the
str_starts_with and str_ends_with functionality again. This is a simple but
highly desired functionality for PHP.

I think you mean PHP 7.4 here. PHP 8.0 is not yet released, and not in
feature freeze either.

> Add str_starts_with, and str_starts_with_ci() functions

The second function should probably be str_ends_with() :)

Nikita

Re: [PHP-DEV] Removing warning for failed include

[Nikita Popov]

On Thu, Mar 26, 2020 at 1:11 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

> It's bothered me for quite some time that a failed include emits a
> warning. This is because it's by design that the author chose
> `include` and not `require`. It's _expected_ that it may fail and they
> are okay with that.
>
> As an example, consider a classic autoloading case. It could be as
> simple and performant as:
>
> $file = /* something derived from class name */;
> include $file;
>
> But because of the warning, in practice authors tend to use
> `file_exists` + require instead:
>
> $file = /* something derived from class name */;
> if (file_exists($file)) {
> require $file;
> }
>
> Weird isn't it? Authors are using require instead of include for the
> case where failure is tolerated. This is a clear signal to me that
> include isn't doing its job. The warning gets in the way.
>
> Any reasons we shouldn't just remove this warning for PHP 8?
>

I don't think this really matches how include is being used in practice. I
think to the most part "include" is just the legacy spelling of "require",
and people are going to be very confused if it can silently do nothing.

If you want to make a change in this area, I'd go for deprecating "include"
to reduce the language complexity in this area (include, include_once,
require, require_once, which should I use in any particular situation?),
though probably the case for that is not particularly strong either.

Regards,
Nikita

Re: [PHP-DEV] Removing warning for failed include

[Claude Pache]

> Le 26 mars 2020 à 03:08, Vasilii Shpilchin  a 
> écrit :
> 
> Hello everyone, 
> 
> PHP also can include from URL. In this case it makes sense to produce warning 
> and do not break execution. 
> 

I don’t think that it makes sense to include from URL, to begin with.

IIRC, the allow_url_include directive was even deprecated as of 7.4.

—Claude

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

Re: [PHP-DEV] Class cast

[Stanislav Malyshev]

Hi!

> Actually it is a simplest case, where only a single information was
> considered. But you can expand it to something more complex, where
> currently you will need create a static method to copy the data, which
> is not a normalized way like cast could do.

You can always use anonymous functions if callable is needed.

> 
> Or you can increase the type of information when possible. For instance:
> 
> function requiresB(B $b);
> 
> But you have only A $a.
> 
> You can create:
> 
> function __cast($value) {
>     if ($value instanceof A) return B($value, 123, M_PI);
> }

That's not a cast. That's creating new object from another object.
Things like this should be an explicit call. Otherwise the meaning of
this code is unclear - it pretends that you just change the type, but in
fact it's a completely new object which can be entirely unrelated to the
old one. Things like that should be explicit.

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

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

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Sebastian Bergmann]

Am 24.03.2020 um 11:06 schrieb Sebastian Bergmann:

I voted "no" for the same reason.


I changed my vote to "yes" because of Nikita's arguments.

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