Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
> > > I have no strong opinion > either way, but anyway it cannot work as is, because var_export > already has a second optional parameter (bool $return = false). > Yes, I meant the third argument. I updated the RFC to reflect that. Sorry. > Moreover the RFC currently says that var_export([1, 2, 3]) produces > ``` > array(1, 2, 3) > ``` > but it actually produces > ``` > array ( > 0 => 1, > 1 => 2, > 2 => 3, > ) > ``` > > Also true, I fixed this in the RFC as well and sorry for the confusion. > Regards, > > -- > Guilliam Xavier >
Re: [PHP-DEV] [VOTE] Userspace operator overloading
On Thu, Apr 9, 2020, at 10:05 AM, Rowan Tommins wrote:
> On Thu, 9 Apr 2020 at 13:18 (and subsequent correction), Dan Ackroyd <
> dan...@basereality.com> wrote:
>
> > > $a = new A;
> > > $b = new B;
> > > var_dump($b + $a); # calls B::__add($b, $a); OK
> > > var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError
> >
> >
> > ... that code does have a TypeError. It is
> > calling '__add' and passing a parameter to the method that the code
> > can't handle.
> >
> > It appears to be the same error case as:
> >
> > ```
> > class A {
> > public function add(A $rhs) {...}
> > }
> >
> > class B {
> > public function add(A|B $rhs) {...}
> > }
> >
> > $a = new A;
> > $b = new B;
> >
> > $b->add($a); // Ok
> > $a->add($b); // TypeError
> > ```
> >
>
>
> As with so much else on this topic, it depends how you think about operator
> overloading - and I think that's why it's so hard to agree on an
> implementation.
>
> It seems that you're picturing the overloaded + as like a normal method but
> with special syntax, so that $a + $b means the same as $a->add($b) and only
> that. In that interpretation, it's perfectly reasonable to have the
> operation succeed or fail based only on the left-hand operand, because
> that's how we're used to method dispatch working.
>
> But if you look at how "normal" operators work, it's far less obvious that
> the order of operands should play any role in that decision. For instance,
> when mixing float and int, the result is a float if *either* of the
> operands is a float:
>
> var_dump(1 + 1); # int(2)
> var_dump(1 + 1.0); # float(2)
> var_dump(1.0 + 1); # float(2)
> var_dump(1.0 + 1.0); # float(2)
>
> Substitute 1 for $a and 1.0 for $b, and you're back to the example I
> originally wrote. Note that this is true even for non-commutative operators
> like exponentiation:
>
> var_dump(2 ** 3); # int(8)
> var_dump(2 ** 3.0); # float(8)
> var_dump(2.0 ** 3); # float(8)
> var_dump(2.0 ** 3.0); # float(8)
>
> My impression is what people consider "good" use of operator overloading is
> much closer to "make things act like built in numerics" than "make
> operators with fancy syntax", so some form of symmetry is necessary I think.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
Idle, possibly naive thought:
When applying operator overloading to objects, perhaps we could simplify
matters by insisting that it only work for directly compatible types? That is:
class Foo {
public function __add(Foo $b): Foo {
return new FooOrChildOfFood();
}
}
It would work for interfaces too, but the point is that you *can't* operate on
just any old other value... only one that is of the same type.
You could technically have a BarInterface, and then only the left-side object
gets called, but it means it has to be combining two BarInterface objects,
which means it knows how, because BarInterface has the necessary methods. If
not, then your BarInterface is wrong and you should feel bad.
This creates a narrower use case, but perhaps one that still fits the practical
usage patterns? (Eg, adding Money objects together, etc.)
If an operator by design wants different types on each side (not for numeric
behavior, but for, eg, a function concatenation operator), then you would have
to type the RHS you expect (eg, a callable in that case).
It's not as extensible, but the extensibility seems like it's the problem in
the first place. I generally agree with those who have said that any such
functionality needs to leverage the type system effectively, not side-step it.
As I said, possibly naive thought, but could deliberately reducing the scope
make life simpler?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
On Thu, 9 Apr 2020 at 13:18 (and subsequent correction), Dan Ackroyd <
dan...@basereality.com> wrote:
> > $a = new A;
> > $b = new B;
> > var_dump($b + $a); # calls B::__add($b, $a); OK
> > var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError
>
>
> ... that code does have a TypeError. It is
> calling '__add' and passing a parameter to the method that the code
> can't handle.
>
> It appears to be the same error case as:
>
> ```
> class A {
> public function add(A $rhs) {...}
> }
>
> class B {
> public function add(A|B $rhs) {...}
> }
>
> $a = new A;
> $b = new B;
>
> $b->add($a); // Ok
> $a->add($b); // TypeError
> ```
>
As with so much else on this topic, it depends how you think about operator
overloading - and I think that's why it's so hard to agree on an
implementation.
It seems that you're picturing the overloaded + as like a normal method but
with special syntax, so that $a + $b means the same as $a->add($b) and only
that. In that interpretation, it's perfectly reasonable to have the
operation succeed or fail based only on the left-hand operand, because
that's how we're used to method dispatch working.
But if you look at how "normal" operators work, it's far less obvious that
the order of operands should play any role in that decision. For instance,
when mixing float and int, the result is a float if *either* of the
operands is a float:
var_dump(1 + 1); # int(2)
var_dump(1 + 1.0); # float(2)
var_dump(1.0 + 1); # float(2)
var_dump(1.0 + 1.0); # float(2)
Substitute 1 for $a and 1.0 for $b, and you're back to the example I
originally wrote. Note that this is true even for non-commutative operators
like exponentiation:
var_dump(2 ** 3); # int(8)
var_dump(2 ** 3.0); # float(8)
var_dump(2.0 ** 3); # float(8)
var_dump(2.0 ** 3.0); # float(8)
My impression is what people consider "good" use of operator overloading is
much closer to "make things act like built in numerics" than "make
operators with fancy syntax", so some form of symmetry is necessary I think.
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] [VOTE] Userspace operator overloading
On 09.04.2020 at 14:41, Dan Ackroyd wrote:
> On Thu, 9 Apr 2020 at 13:18, Dan Ackroyd wrote:
>
>> It appears to be the same error case as:
>>
>
> And that code had a mistake. Should have been:
>
> ```
> class A {
> public function add(A $rhs) {...}
> }
>
> class B {
> public function add(A|B $rhs) {...}
> }
>
> $a = new A;
> $b = new B;
>
> $b->add($a); // Ok
> $a->add($b); // TypeError
> ```
If we'd go with (dynamic) methods, wouldn't we have to add "r"-methods
(like Python does) as well? And if we did so, wouldn't we encourage
misusing operator overloading for all kinds of stuff (for which it
shouldn't be used, in my opinion)?
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)
> On Apr 9, 2020, at 02:29, Côme Chilliet > wrote: > > Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit : > >> **Lesson:** Of functionality that can be accomplished in userland, only >> trivial/simple functionality is acceptable. > > My take on that is more that functionality in core needs to be «perfect», or > at least near unanimous. And of course it’s way easier to find a solution > which pleases everyone when it’s for something quite simple. Ah, yes, that latter sentence makes for a a subtle difference, and I think a fair one. Nicely said. -- 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] Re: Resurrecting named parameters
On Tue, Apr 7, 2020 at 2:44 PM Nikita Popov wrote:
> Hi internals,
>
> It's been a few years since I originally brought up the named parameters
> RFC: https://wiki.php.net/rfc/named_params
>
> This topic has recently come up as part of
> https://externals.io/message/109220 again, in particular with the
> observation that the combination of constructor parameter promotion and
> named parameters will give us, as a side-effect, an ergonomic object
> initialization syntax that is well-integrated with the remainder of the
> language.
>
> I've reimplemented basic named param support for master in
> https://github.com/php/php-src/pull/5357, but before going any further
> here, I want to restart discussion on the various open issues that the
> named parameter concept in PHP has. I think there's two primary issues:
>
> ## LSP checks for parameter names
>
> Parameter names currently have no particular significance in PHP, only
> their position in the signature is important. If named parameters are
> introduced (in a way that does not require opt-in at the declaration-site),
> then parameter names become significant. This means that changing a
> parameter name during inheritance constitutes an LSP violation (for
> non-constructor methods). There are a number of ways in which this issue
> may be approached:
>
> 1. Silently ignore the problem. No diagnostic is issued when a parameter
> name is changed during inheritance. An error exception will be thrown when
> trying to use the (now) unknown parameter name.
>
> 2. Throw a notice if a parameter name is changed. While LSP violations are
> normally fatal errors (in PHP 8), we could use a lower-severity diagnostic
> for this case, that allows code to still run, but makes developers aware of
> the problem. (It should be noted that automatic fixup of parameter names
> using tooling should be fairly easy to implement.)
>
> 3. Allow using parameter names from the parent method, even if they have
> been renamed. This makes things "just work", but seems fairly magic, and
> has edge cases like a signature foo($a, $b) being changed to foo($b, $a),
> where it's not possible to implicitly support both at the same time.
>
> 4. Make named-parameter opt-in in some fashion, so that parameter names
> only need to be preserved for methods that have the opt-in marker. I'm not
> a fan of this, as it greatly diminishes the practical usefulness of named
> parameters.
>
I've done some due diligence on this issue, and checked how other languages
with named parameters handle this, and also did some quick checks on what
the fallout looks like if we add a notice.
## C#
C# does something fairly peculiar. Changing the parameter name introduces a
new Schrödinger's overload: We use "new" here to indicate that the parent
method is hidden, and it would be if we invoked positionally, but we can
actually still access the parent method by performing the call with the old
parameter name. This seems pretty weird to me.
```
class Test1
{
public void test(int x) {
Console.WriteLine("X: {0}", x);
}
}
class Test2 : Test1
{
public new void test(int y) {
Console.WriteLine("Y: {0}", y);
}
}
public class Program
{
public static void Main()
{
Test2 test2 = new Test2();
test2.test(y: 42); // Y: 42
test2.test(x: 42); // X: 42
}
}
```
## Python
Unsurprisingly, Python just ignores the problem. If you use the name from
the parent, you get an error.
```
class Test1:
def test(self, x):
print('X:', x);
class Test2(Test1):
def test(self, y):
print('Y:', y);
test2 = Test2();
test2.test(y=42); // Y: 42
test2.test(x=42); // TypeError: test() got an unexpected keyword argument
'x'
```
## Ruby
Similarly, Ruby also ignores the issue. It should be noted though that Ruby
distinguishes keyword arguments from positional arguments, so you need to
opt-in to their use (and if you do, they must be used at the call-site).
```
class Test1
def test(x:)
print('X: ', x)
end
end
class Test2 < Test1
def test(y:)
print('Y: ', y)
end
end
test2 = Test2.new;
test2.test(y: 42) // Y: 42
test2.test(x: 42) // missing keyword: y
```
## Kotlin
Kotlin does what is reasonable: There is a warning about the parameter name
change at the declaration-site, and a compile-error at the call-site.
```
open class Test1 {
open fun test(x: Int) {
println("X: $x")
}
}
class Test2 : Test1() {
// Warning: the corresponding parameter in the supertype 'Test1' is
named 'x'.
// This may cause problems when calling this function with
named arguments.
override fun test(y: Int) {
println("Y: $y")
}
}
fun main() {
val test2 = Test2()
test2.test(y=42); // Y: 42
// Error: Cannot find a parameter with this name: x
test2.test(x=42);
}
```
## Swift
Swift behaves somewhat similarly to C#, in that by default changing the
parameter name introduces a new overload. In this case it's a proper
Re: [PHP-DEV] [VOTE] Userspace operator overloading
On Thu, 9 Apr 2020 at 13:18, Dan Ackroyd wrote:
> It appears to be the same error case as:
>
And that code had a mistake. Should have been:
```
class A {
public function add(A $rhs) {...}
}
class B {
public function add(A|B $rhs) {...}
}
$a = new A;
$b = new B;
$b->add($a); // Ok
$a->add($b); // TypeError
```
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
On Mon, 6 Apr 2020 at 20:36, wrote:
>
> Hi internals,
>
> I have closed the voting. With 38 in favor and 28 against the RFC is DECLINED
> (didn’t reach the needed 2/3 majority for a new feature).
>
> Thanks to everyone who has participated.
>
Hi Jan,
Thanks for running the RFC. Although it didn't quite pass it seems a
lot closer now.
Apologies for not taking part in the discussion earlier, but I'm slow
at thinking. To follow up on a couple of things.
> If it can not handle the given type, it has to return the
> constant PHP_OPERAND_TYPES_NOT_SUPPORTED (currently just null).
This does not appear to be a good choice. It means that to evaluate
whether the code is safe to call the code needs to be evaluated. That
makes doing static code analysis very difficult.
Also, it means that operators could not return null as a result of the
operation, which seems like an odd choice that would be a regretful
limitation.
Rowan Tommins wrote from https://externals.io/message/108788#108993 :
>
>
> $a = new A;
> $b = new B;
> var_dump($b + $a); # calls B::__add($b, $a); OK
> var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError
And jan.h.boeh...@gmx.de wrote:
>
> If an operator handler has typehints, an error will be thrown,
> What do others think about this restriction?
I think that is the wrong solution to the wrong problem.
It's a wrong solution because parameter types* are a useful tool both
for program correctness at runtime, they make it easier to run static
code analysis tools on the code and most importantly they save a lot
of developer time, mostly through autocomplete.
It's the wrong problem because that code does have a TypeError. It is
calling '__add' and passing a parameter to the method that the code
can't handle.
It appears to be the same error case as:
```
class A {
public function add(A $lhs, A $rhs) {...}
}
class B {
public function add(A|B $lhs, A|B $rhs) {...}
}
$a = new A;
$b = new B;
$b->add($a); // Ok
$a->add($b); // TypeError
```
For me, the solution to the error in this code is not "remove the
parameter type on A::add". I'm pretty sure that the solution to this
type of error would be "fix your code".
When someone looks at the idea of userspace operator overloading
again, I think the following path might reach a more acceptable
solution.
* Encourage people to use parameter types to make their code easier to
reason about.
* Encourage people to use static analysis to check their code for
errors, including errors where they have invalid operands to
operations.
* Take the approach in the RFC that passing a wrong parameter type to
an operator magic method represents a programming error that cannot be
handled in the normal program flow, and that throwing an exception is
the right thing to do here**. But as most people should be using
parameter types, and static analyzers to check for this type of error,
this should not occur.
Other than a learned reticence against throwing exceptions, what
downsides would that have?
cheers
Dan
Ack
* PHP has parameter types that are checked at runtime, not 'hints'
that can be worked around as found in other programming languages. If
people would stop using the phrase 'type hint', it would make the
conversation more accurate.
** This is not using exceptions for flow control (though it could be
abused for it). Most people should be avoiding these problems through
writing code correctly, and using static analysis to double-check
their code is free from errors.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Allow trailing comma in parameter lists
On 09/04/2020 10:50, Guilliam Xavier wrote: I'm personally favorable, but since some concern has been raised that it *might* be interpreted as "encouraging" functions with many parameter The only comment I saw was from Jakob Givoni that said: "Are we encouraging functions with long lists of parameters so that they need to be on their own lines?" The answer to that is a pretty resounding "no". Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Allow trailing comma in parameter lists
On Thu, Apr 9, 2020 at 10:02 AM Nikita Popov wrote: > > 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 > > > > Heads up: I plan to move this to voting tomorrow. Don't think there's much > to discuss here... > > Nikita Hello Nikita, I'm personally favorable, but since some concern has been raised that it *might* be interpreted as "encouraging" functions with many parameters (and I fear that could be taken as a motive for voting "no"), I would just suggest (again) that you could add an example (or even replace the current one) of a function with only two/three parameters that would still exceed 120 columns if on a single line (with e.g. descriptive names, [union] type declarations for parameters and/or return, and/or a class constant as default value for the last parameter, that's not so uncommon)... Just my two cents ;) Best regards, -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Type casting in array destructuring expressions
Hi together, I have opened the voting for adding type casting in array destructuring expressions: https://wiki.php.net/rfc/typecast_array_desctructuring As the future scopes section of this proposal includes additional possible topics (eg. strict casts or the alternative solution via regular type checks in array destructuring expressions) I've included an additional poll to see which of these topics may be tackled in the near future. Voting closes on April 23th. Thanks for everyone participating in the vote. Cheers, Enno
Re: [PHP-DEV] [RFC] Change default PDO error mode
Hi all, A quick "bump" to make sure everyone's seen this RFC amongst all the other exciting discussions that are going on. I'm hoping the lack of discussion means this is a boring obvious change that everyone's going to vote 'yes' to. With the lack of any raised concerns or issues, I intend to open voting this weekend. Regards, AllenJB On 28/03/2020 19:02, AllenJB wrote: Hi, I present for discussion an RFC to change the default PDO error mode: https://wiki.php.net/rfc/pdo_default_errmode Previous discussion: https://externals.io/message/109015 I believe this change will help new developers who are presently presented only with knock-on errors, which can be confusing, when using PDO unless they implement "boilerplate" error handling every time a query is made. I believe it also brings the behavior inline with what developers would actually expect the default to be in modern PHP. Regards, AllenJB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Allow trailing comma in parameter lists
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 > Heads up: I plan to move this to voting tomorrow. Don't think there's much to discuss here... Nikita
Re: [PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)
Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit : > ## Lessons Learned > > ### Userland Functionality > > The initial impression is that there is a strong desire for work that *can* > be done in userland to *stay* in userland. However, that impression conflicts > with the recent acceptance of `str_contains()`, which is very easily done in > userland. > > **Lesson:** Of functionality that can be accomplished in userland, only > trivial/simple functionality is acceptable. My take on that is more that functionality in core needs to be «perfect», or at least near unanimous. And of course it’s way easier to find a solution which pleases everyone when it’s for something quite simple. I do think OO interface for request/response in core is something that could pass, but it would need to be more in line with what people want/expect. > ### Userland Ecosystem > > There was somewhat less concern for "the ecosystem," but it too was prevalent > in the discussion. > > **Lesson:** Perceived challenges to popular userland projects are going to be > met with strong resistance by their existing stakeholders, even when an RFC > is explicitly not a challenge to them. You clearly disagree on this with most participants in the discussion, but saying «this RFC is not a challenge» is not enough to make it true, there was a clear overlap of feature between your RFC and existing userland projects so it made sense to compare them. -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
