Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111204 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39751 invoked from network); 28 Jul 2020 00:25:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jul 2020 00:25:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EF6261804B4 for ; Mon, 27 Jul 2020 16:21:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 27 Jul 2020 16:21:36 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id t18so13601834otq.5 for ; Mon, 27 Jul 2020 16:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JuwvjRPFO2EA7zz4BBiwm6pAtdLSNlzE0Mum/adNU3E=; b=RjP8s3tisi8h0S9Ka2mQHS2k8Mj8GjzObbmNvMnU+rye02iJLrGhZ3O5jnmmfTWSVI Vq+gQKqUfhz1kGGztNv/PmiLINTyz58hKldaQih0e/FHls6SM7qfXZS5jhbPN8ZL7EHK Jtg2pjBQvqXd8yhkQMDBff4MOzkzrpldGdmSc1MrFy5B9VLyBMZCpJ1Kx25f6D6tAgop S5kC4fBddpmGGJKFq5YAwK3e8Z0O+xMFEg0riyDyOsJ9DRFDTsEm2235uYFnHvhWcuTl r4/DCDhUxywcPvAWE/sSr6LvVob/cDwfw3TH0Z+FxNTPxnFDc2EORY6O+qGjfT1/bNIt 5zzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JuwvjRPFO2EA7zz4BBiwm6pAtdLSNlzE0Mum/adNU3E=; b=RBBE0dKfD4KAo7Ig0ggu/bjxw0sKiBtRgSTKZ7Z/Vuz1Ho9CQpMOqOzZ+BATevlhvG R9JnbFLiGNGJ1Z1AWWv6JKRCQ/pVM6U4qiKgyGeeg1GCIIa2JVbRm17k1kRn7kVy0+iO oEDn/u7FUi/Zy3GT7UHjvI8vYDy5n049JSdCjTvfdhmFm1bYZ5MmyY7UrcsVJ3MsIkZk MtSqSx0hUmQkkxrlM3u6WV8LU3j6LrecNi0bs/hnLZgXlKNqz/jTcxBThLDhEGkWRRar v2tFbXp+BhhznQwPzb34sWJ5kiY0aOQXb59BTd4cqp1JUlqTN9j4RIaj2jcsDi2BUz5+ wmvg== X-Gm-Message-State: AOAM532Jb8/BbcWrKFFkFYJErYSOvfrcasq4mqqaZf2M4+VGjpuKt6vm p5+E6zPffJumUC40djy5bzBnNWOqC94KLgsM/BQAQg== X-Google-Smtp-Source: ABdhPJxGs7D9MpHtQ94tWNeKh72jM9+6GVzC+CZYuqe/mqZjuhd7pJRSn/7he2OD7tQ0rZadPha8zQ5JjtbDeBiCekw= X-Received: by 2002:a9d:4002:: with SMTP id m2mr22428389ote.129.1595892095382; Mon, 27 Jul 2020 16:21:35 -0700 (PDT) MIME-Version: 1.0 References: <0836b5cd-ec21-c383-4f68-0cabaf1adaf6@gmail.com> In-Reply-To: <0836b5cd-ec21-c383-4f68-0cabaf1adaf6@gmail.com> Date: Tue, 28 Jul 2020 01:21:24 +0200 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000720e0d05ab749526" Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters From: andreas@dqxtech.net (Andreas Hennings) --000000000000720e0d05ab749526 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good point about the static typing! On Mon, 27 Jul 2020 at 20:40, Rowan Tommins wrote= : > Hi Andreas, > > > On 27/07/2020 00:41, Andreas Hennings wrote: > > 1. Calls with named arguments can only happen on: > > - explicitly named functions (e.g. no call_user_func()). > > - constructor calls with an explicitly named class. > > - object methods, if the object variable is type-hinted or a type is > > known at compile time. > > 2. Named arguments in calls are converted to number-indexed arguments a= t > > compile time. > > 3. Parameter name lookup is done based on the type-hinted class or > > interface. Parameter names on the actual object are ignored. > > > While this is an interesting concept in general, it introduces a much > larger change to the semantics of the language than seems justified for > this particular problem - it would effectively require introducing an > element of "static typing" into the language. > > By "static typing", I mean this: > > > variables have an intrinsic type, and the same value can behave > differently depending on the type of variable that holds it > > Which could be contrasted with "dynamic typing" like this: > > > values have an intrinsic type, and operations will be selected based > on those values, regardless of which variables hold them > > Although we have various type annotations in the language now, they are > all just restrictions on the types of value a variable can hold; they > don't change the behaviour of that value. With this proposal, these two > function would potentially do different things when given the exact same > argument: > > function a(FooInterface $arg) { $arg->doSomething(namedparam: 42); } > function b(BarInterface $arg) { $arg->doSomething(namedparam: 42); } > It would be an edge case, if both of them are valid but with swapped parameter names. In the more common cases, one of them would simply be broken. But your point is still correct. I would argue that this is still better than the behavior with the current RFC: The developer who implements the function a or b only knows the parameter names as in FooInterface or BarInterface. They know nothing about the actual class of the object passed in as $arg. A name lookup based on the known interface is closer to what the developer wants, and is guaranteed to work for all implementations of the interface. The main inheritance contract for methods is still based on parameter order= : E.g. interface I { function foo(A $x, B $y); } interface J extends I { function foo(A $y, B $x); } The parameter names can be swapped, but the types have to remain in order. > > > Static typing of that sort is a useful feature of other languages, and > there are people who'd love to see PHP go that way, Count me in :) > but it's not > something we should bolt on in a hurry just to solve an issue with named > parameters. > You have a point. It would not be a full-blown static typing, but at least it has the smell of it. The parameter name lookup would be based on the variable itself, instead of the value. As mentioned, there could be other ways to determine the version of the method that should be used for parameter name lookup. The options I can come up with atm would make the code more verbose, and/or look awkward, and probably already clash with existing language features. But perhaps there are better ways. Either in the call itself: $x->{FooInterface::doSomething}(namedparam: 42); FooInterface::doSomething::invoke($x, namedparam: 42); Or through a declaration in the file: use \Acme\FooInterface::*(); $x->doSomething() > just to solve an issue with named > parameters. I still think the current RFC is deeply flawed and should not have been accepted in its current form. It adds uncertainty and fragility to the language. The Liskov substitution principle was something we could rely on, guaranteed natively by the language. But with named parameters it is not. I saw the explanations in the RFC about inheritance, but I don't find them convincing. But I am not a voting member and also I did not pay attention when this discussion was happening. And I am just one person, I don't want to make more than one person's worth of drama. Perhaps we will see people mostly use this for constructor or static calls, and avoid it for polymorphic method calls. For these cases it seems like a useful feature. > > > Regards, > > -- > Rowan Tommins (n=C3=A9 Collins) > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --000000000000720e0d05ab749526--