Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110050 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 2642 invoked from network); 6 May 2020 21:32:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 May 2020 21:32:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1C2AB18050A for ; Wed, 6 May 2020 13:08:00 -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=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 ; Wed, 6 May 2020 13:07:59 -0700 (PDT) Received: by mail-wm1-f43.google.com with SMTP id v8so5789104wma.0 for ; Wed, 06 May 2020 13:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:cc:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5LO04iViekXXEm9lnDN0M0DnUXXSljMaw+MrOywNKIY=; b=I5G2s13LKI0ARe1lRkF99vpyjQLTHyHFt2/bg88jrhAbmUCOKCh6z94yEhzeYbC29r YXaW9QiPl5iq5Jx+jauArH6hbP+nIA/SAhyVHQWGQeSjbF1vapV4uulzNapRatN1hGNj HyAwUUK2VDof9WUjnsbHl6eCGwz9hTPxIkriED5Pd521ljvQVdhdRlcJSRRYOJQUlpOn t0ymS3QMDjNS+W06y/9aK15GjkTdRa3W8dYcy/wFVK860lH61fBioZH0aZXTyHtbPgId ZO4r9VOJUShu5JrgJ1iBawHmo1qefAbaHYHYOW1JNGeIRC+z90PFFjj77jPNkPW0pF0J HszQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5LO04iViekXXEm9lnDN0M0DnUXXSljMaw+MrOywNKIY=; b=VyjKnoltDIs3xMwce2LoseN94g4cAqreoHn0fOmBLKdy7CS+vlaO59eoui7TeAG4L6 dpAI2yh/u7tz6xnQVVeMprSLoesDEhTKxs2TVkbxcr9/LRgTOaGGh3L1mptYJoF1iFqR DoAMvefqVCTSt+E2GGkI3AK+O5ubD5K6QKbJxsAi6DfmQC+I2VeJuAM/DWigGz4y1AcW nwlj/SonRdSUICxcI55hOnoK5eyhbL+ZxlRiKIt99K558w0BSVw7wSgjjyAbBSlxEqEp jewBIxG5Xqx0+xfVVCULTaTEFSule7JJ+4iV4MBDJH1W9I/INHFaDNl5tma9anX93egu iBmw== X-Gm-Message-State: AGi0PuZgXdNvrMTG8SfvakyT3IrNVL6VT4G1lRptZMN5KA/KSfQy6CzK L6P7JL5/DUzCSTVO08wSxqBrLl3Z X-Google-Smtp-Source: APiQypKAZjPJ91aQS8zFLiQmLsCOx92LD4D8DtNmnSNPVy4mlQcSCfivZhOGjhBvKj70SGLc7ErBXQ== X-Received: by 2002:a7b:c931:: with SMTP id h17mr6616607wml.105.1588795676963; Wed, 06 May 2020 13:07:56 -0700 (PDT) Received: from [192.168.0.14] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id g24sm4603260wrb.35.2020.05.06.13.07.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 13:07:55 -0700 (PDT) Cc: internals@lists.php.net References: <439e7c43-8d17-1398-d72e-c7ae6942ce86@gmail.com> <8A17FF2D-9CD4-4DF2-B352-7079FCC7F104@zort.net> Message-ID: <8903bb46-c061-c34f-8a6f-56c0117cf642@gmail.com> Date: Wed, 6 May 2020 21:07:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8A17FF2D-9CD4-4DF2-B352-7079FCC7F104@zort.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Named arguments From: rowan.collins@gmail.com (Rowan Tommins) Hi John, On 6 May 2020 19:18:41 BST, John Bafford wrote: >You're not wrong here, but, I think that's an (critical) implementation >detail of Objective-C and Smalltalk that is not relevant here. Also, >Swift does not use selectors or message passing, unless either >interoperating with ObjC classes, or the code has explicitly opted-in. >Normally, Swift function/method calls are statically determined at >compile time in a way similar to C/C++. It may not use the same mechanism to dispatch them, but the concept of "parameter labels are part of the function name" is still very much present, and is very different from named parameters in other languages. >I don't think any of your points are downsides to the proposal. A lot >of these I think boil down to the conflict between, "as an API user, I >should be able to do whatever I want", and, "as an API author, I have >decided my API will be used like this". I generally side with the API >author being specific on how their API will be used. I think this is the same argument people have over the strict_types declaration: should a library be able to constrain how users write their code, even if it makes no difference to how the library functions? With strict_types=0, a user can ask the language to convert a string to an int on-the-fly, and a library author gets the int they asked for. Similarly, named parameters allow users to call a function with arguments in the "wrong" order, but the library author is guaranteed they'll all be there. You could put partial application in the same category: it allows a user to reuse your function without specifying all the parameters each time! Ultimately, even if the language didn't provide mechanisms for any of these things, a user could write a wrapper that did. I'm not aware of a programming language where libraries have the power to stop that, and I think making it easier is a Good Thing: it allows users to reuse each other's code, but adapt it to their own coding style. >If a function/method has labels, you're required to use them. >Otherwise, you can't get the benefit of using them for name-based >"overloading". This is why I said earlier that I think Smalltalk-style function naming is solving a different problem from named parameters. Smalltalk was explicitly trying to make programming read like natural sentences, and it used these multi-part names as a way to do that. That's a really interesting concept, but it's not the feature that people are asking for in PHP. And the restriction it places on how functions are called directly works against solving the problems that named parameters would solve. > Because there's generally only a few "correct" ways to word most sentences. > In that regard, AMQP::queue_declare is a pathological exception. There may be a good > reason for its specific order, but lacking that knowledge, it appears > to be completely arbitrary and nonintuitive. It may be a "pathological exception" if you define the problem as "how can we make methods read more like sentences"; but that's not the problem I see named parameters as solving. The way I see it, requiring a specific order for those parameters is itself an arbitrary constraint. An example that's come up frequently in the thread is constructing simple data objects. The actual requirement is "provide appropriately-typed values for these N named fields"; in many cases, there is no "natural order", and no particular value in the library author choosing an order, *except that the language forces them to*. Internally, the compiler / runtime needs everything to have an address in linear memory; but humans like to give things names. Rather than: function strpos(string $1, string $2, int $3) { ... } We prefer to define: function strpos(string $haystack, string $needle, int $offset) { ... } Within the body, we don't have to worry about the position of $haystack and $needle in memory, we just use their names. Named parameters are in a way just an extension of that; rather than: strpos("hello", "l", 3) We can write: strpos(haystack: "hello", needle: "l", offset: 3) Or: strpos(needle: "l", haystack: "hello", offset: 3) The order of parameters is no longer relevant; we've given them names, and the compiler can sort out where they need to live in memory. >If I said to someone, "language the hard improve working We constantly >PHP to are", they'd probably look at me funny. We don't accept people >speaking human language with randomized word order; neither should API >authors (or other developers) be expected to accept people using APIs >with randomized parameter orders. I you typed that into a special accessibility aid, and it was automatically translated into the correct order by predictable rules before I saw it, I a) wouldn't even know; and b) would be happy you were able to use that aid to communicate with me. Similarly, if you write a function and somebody can call it using their preferred style that still guarantees the signature is followed, that's a win for everyone. Regards, -- Rowan Tommins [IMSoP]