Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110005 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 70015 invoked from network); 5 May 2020 15:36:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 May 2020 15:36:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3AFEF1804F4 for ; Tue, 5 May 2020 07:11:29 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, 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-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (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 07:11:28 -0700 (PDT) Received: by mail-il1-f169.google.com with SMTP id x2so1129324ilp.13 for ; Tue, 05 May 2020 07:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=atg+8DJRIwlKlzKayh3cxaeGJppVkPqn7soVxZE/YbE=; b=Cc07L5Y6/NH/KsXDmnww/xQXwFPUIFxHo2TB6OUEpaWbPoJYK5xRasc9F3NVntwrL1 tUsC5Xf/nQrk3HpZ+Z9a0QDE6B5ENL8C3M00QwxnTq8xUlxAFj7Yk5sRE1ti3cdut+30 mIF0imjYJWHbJp/2BNtNiPqeiHQphaAWk41G2JYNYyNv1eqm+6hHLYWmJUDFNd5FFOS1 gWzQiBiRzDmQuw9UrdnuO7wAIUI62xrmkT9+OX972ZSbP2QKaSbCQXSPwNMcHPLd3He/ 2qQqMOPMgU4CjiTEpKci2ART3O/ruIW+PZMPntjwRRSwLRoqxAlKNQl4vzeLVVpsQ3z8 8h9A== 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=atg+8DJRIwlKlzKayh3cxaeGJppVkPqn7soVxZE/YbE=; b=lcoc9aztz/Kf4aTJ4qedcW2N21VJHDFEeDHBOWd2SuKIch07+dOP14Qb0DIC8U6gDr OIUVs0sheaGYh2GbaBrI+WpS0HjPsLuP1N1yFxxPnNsGnVmg3pjwAsSr+qW24B5baYaf s84zVjyDEc0bVwR9gxJFTcvKN2RxQiHYu4v9JP7VllrnDChhMlqjpVp7sECxle9NiD14 Mum+LAPUmzeCitfeTT8x2KrwACXXOoMmFtmBWskVofv7iEf2m5E5ORA3Ly+z8rYCxXWJ cjqo3rmwWY1oqQc8g318BI2lMzLxuCpD/ZKHtgxKTQiz03TiqIC7+xWeNdY/C4ruL6SK DugQ== X-Gm-Message-State: AGi0PubJPxrFg51WBjvqqRVzCrV5U6lU5mVqZ3KZJx/3+OPZ0weuSvlP dzPaXkU8Xm4QakbDkt+95+5Ki6SmA1Po8eQLUPmmUtGgssM= X-Google-Smtp-Source: APiQypL7j/W3OEBvJQ/tJuLHfPVzizsA64sT5Yk3v7yJtxBHVEvar4br7mwsaHoQW4YFkvG4nPVREcO9ZV5g+ert4r0= X-Received: by 2002:a92:cc4a:: with SMTP id t10mr3858539ilq.292.1588687886632; Tue, 05 May 2020 07:11:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 5 May 2020 16:11:14 +0200 Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000244c4f05a4e7395f" Subject: Re: [PHP-DEV] [RFC] Named arguments From: ocramius@gmail.com (Marco Pivetta) --000000000000244c4f05a4e7395f Content-Type: text/plain; charset="UTF-8" Hey Nikita, On Tue, May 5, 2020 at 3:51 PM Nikita Popov wrote: > Hi internals, > > I've recently started a thread on resurrecting the named arguments proposal > (https://externals.io/message/109549), as this has come up tangentially in > some recent discussions around attributes and around object ergonomics. > > I've now updated the old proposal on this topic, and moved it back under > discussion: https://wiki.php.net/rfc/named_params > > Relative to the last time I've proposed this around PHP 5.6 times, I think > we're technically in a much better spot now when it comes to the support > for internal functions, thanks to the stubs work. > > I think the recent acceptance of the attributes proposal also makes this a > good time to bring it up again, as phpdoc annotations have historically had > support for named arguments, and this will make migration to the > language-provided attributes smoother. > As mentioned some days ago, I see named parameters as an added liability, rather than values. The rationale of my negativity around the topic being that a diff like following is now to be considered a BC break: ```diff -function foo($parameterName) { /* ... */ } +function foo($newParameterName) { /* ... */ } ``` In addition to that, the feature seems to be especially designed to work with particularly bad API (anything with a gazillion optional parameters, such as all the OpenSSL nightmares in php-src). In practice, the issues around bad API (in this case, bad = lots of optional parameters, maybe even ordered arbitrarily) are fixed by using proper value types and structs or value objects: ```php myHorribleLegacyAndOrganicallyGrownApi( ...MyInfiniteSequenceOfParametersAsProperValidatedStructure::fromArray($stuff) ->toSequentialParameters() ); ``` For the few use-cases where this is needed, the userland solution seems to be sufficient, without introducing catastrophic BC boundary expansions. Unless I'm not seeing an incredible (hidden, to me) value from this functionality, this is a clear -1 from me. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --000000000000244c4f05a4e7395f--