Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110025 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 61042 invoked from network); 5 May 2020 22:12:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 May 2020 22:12:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C56AA1804C9 for ; Tue, 5 May 2020 13:47:11 -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.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) (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 ; Tue, 5 May 2020 13:47:11 -0700 (PDT) Received: by mail-wr1-f65.google.com with SMTP id l18so4338790wrn.6 for ; Tue, 05 May 2020 13:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=t80FlgJheYGW44G+blfZ4ZVYv/7YSmVQMIPPjH4qq9M=; b=HQCbI0U4IaaF+dI0iHVx/8mL795fd0BFI4oPv9DLgijToZfu564QQOxXZUIMq+E9K4 NIsG9py5AENoZGgsGlAVbRWDyNeFL4azU7Lua6TtoilkjoKtaGwlQkkedbOeadJEQLrT 509WU1UBxq1TWiGlkj1IZMH2xJniMAmzcZXUm0Osk+QjNwe5p3MS6dbTEFrOKanVV2pH OFJysLyVxBe4mQANZIpIhk6Z7fMZxtQghI6rRpiJDOdJRasHbOQbHoHV/3CLdojgGjTa RJoT6hX+n1guRT1/GEv3CN+A1o7ft9zZYtONIWflT8TnV63E5V3yhmL6eWcZTuTUHaWN PFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=t80FlgJheYGW44G+blfZ4ZVYv/7YSmVQMIPPjH4qq9M=; b=aj97b6MjJNn1llbIj7Y+HGf/zaybXTnZ5jDBvFIq7etEFTL295xVz/LmmoA+qLfneD Ls3wqFwnJhilJpA2werPOK2FuZbyiUzs6I/SpWAfWi4Rz03QcgfGjgV8Kyh13Oh6p0aP muhqjFwalq1zzmG4JKoKpYDfGXiPqlszUlumF9+UbN4Q54oFMAWc7vqkKOjJkdwQITmI j/kcjbtfg4EU+/MW4MzbwDfBwHnT6YrIr/FpCuAS68DemMUKR8IR2l8EW3OmMWpzmvx1 L1EAsuAjUwsduFRgZqhTBEBW/6exzZJTbivXxOG4QwWc5sVNvi0Qaw7d9byj0qokyWu1 HfSw== X-Gm-Message-State: AGi0PuY55+KmmNT9EnhatJhnnO61neA+UASFpGx2dszCdWX2XEMj3rDy dnAvY9NZEXd3LGAZ+4UNKvoIxrNr X-Google-Smtp-Source: APiQypJtHMgkBmpK07pFk900RfzC+PT96Ncc+5LgHPvq3XgabpfvnPY3mFBEoS/DZ5wtZlZbHwArWg== X-Received: by 2002:a5d:5261:: with SMTP id l1mr5539846wrc.24.1588711627231; Tue, 05 May 2020 13:47:07 -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 a7sm5571565wmj.12.2020.05.05.13.47.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 13:47:06 -0700 (PDT) To: internals@lists.php.net References: Message-ID: <439e7c43-8d17-1398-d72e-c7ae6942ce86@gmail.com> Date: Tue, 5 May 2020 21:47:05 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] Named arguments From: rowan.collins@gmail.com (Rowan Tommins) Hi John, On 05/05/2020 18:27, John Bafford wrote: > I very much do like the idea of named parameters, but I do not like the specific proposal in the linked RFC at all. I think that treating named parameters simply as syntactic sugar is not a good approach. If we're going to add named parameters, I think they should actually be significant in their own right. As such, please allow me to present an alternative. > > I would propose the following opt-in mechanism, which would work by treating the parameter names as*part of the function name*. Doing it this way I_think_ should allow for no backwards compatibility issues with existing code and would especially give library authors full control over the naming and presentation of their APIs. I really like *some* of this proposal, but I think some of it is solving a different problem. You mention in a later e-mail that you've been heavily inspired by Swift; Swift in turn was inspired by Objective C, which was inspired by Smalltalk. This is an important piece of history, because Smalltalk doesn't actually have methods with named parameters; it has "keyword messages" whose "selectors" are things like "indexOf:startingAt:". Swift makes them look more familiar by keeping part of the name separate from what it calls "argument labels", so a method might be called "indexOf(_:startingAt:)" or "index(of:startingAt:)". Although at a glance these look like named parameters, and they solve some of the same problems, they're actually a fundamentally different concept. They have some nice features: * Method calls can be made to read like sentences * The external API of the function is kept separate from the internal implementation * You can skip over default arguments by omitting their labels * Overloading what looks like one method, by having different methods whose names start the same but have different "argument labels", may be appealing But there are some crucial limitations: * You can't call a method without using its labels; you'd need to have a separate method with a similar name and no labels * Similarly, it's up to the method's author to have versions with a mixture of unlabelled and labelled parameters, so a call like "create('hello', 42, locked: true)" is only possible if that specific variant is defined * You can't use the labels in the "wrong" order, you have to know the order they come in; so it doesn't solve the haystack/needle problem, except by creating extra function definitions * Similarly, methods with large numbers of arguments are still hard to use because you need to know both the name *and* the relative position of the arguments you're providing (imagine defining variants with every order of the 5 bit flags in the AMQP example in my earlier e-mail) It would be possible to take the "outside name is different from inside name" concept and apply it to named parameters proper. But the problems I would like to solve with named parameters wouldn't be solved by Swift/Smalltalk style functions. Regards, -- Rowan Tommins (né Collins) [IMSoP]