Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108954 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23503 invoked from network); 10 Mar 2020 17:04:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Mar 2020 17:04:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1348518054A for ; Tue, 10 Mar 2020 08:24:58 -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-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (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, 10 Mar 2020 08:24:57 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id h131so12468193iof.1 for ; Tue, 10 Mar 2020 08:24:57 -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; bh=PSV2o9WuBRrZ9rdZZtcLfHUHwlZcwuUUN5I2Qn8VAA0=; b=QQ3y1kaw1Puoh2rYSQ9uOJV87lCR+Vwrbe3IEiKHcHpxwGgCTzwfbHy8mLTOuUk0KO A3oNHJ/LTWypPXD9R03NlKQZCcF5ry1O9ZEtimHhZTNBxzHwhYSCkubfq40ekt3SLIV7 C+bpByRA+wxT9VnjFqwJVkJ9h4wlYUAuS9zB5CwPc53Z+7CNukHVJxSy2REaBMZS9Ssq hOl24OAN68Brtkyo2pERQ5oZMzr77AHivZweD/Jpa+2IOxtpBa8Aro+yolThDcp4HkMI K4ZarNBGBMQu1dryBPIb7B2pT3HRVyJIpORIvFp/OHjhympi9Aqbiuhn/tiXdfbSVEEG Qu0Q== 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; bh=PSV2o9WuBRrZ9rdZZtcLfHUHwlZcwuUUN5I2Qn8VAA0=; b=L4KgUDfWmvpZXSOd3QYDd8Z4XKf+TnAIFUxR3MiFLbcXN0cj2h94N63ljkPVVVAILs SUyD0cdeHkciNsJT8TFuxkTrs9c5HPLv8mRPnHI5JZlWtF/K/K93az2diMSG6duH/yA3 AIluVEzyWgvl7PiXDC/Hj9q6RRqN06niEemgerKkPzLoSHPU3lD2wzJLW0JDBMNV21QC 3Hgc0g4GqA9gPqvjVTTQSpsmo9ap8C1CJONtmYLWVZrOA5lXQBAPGtSZaOXFI6gemQkU zG9nBeBs3jJ6ce9kDx00oEbspWt0UI6zQBmRjM3iDarcEX9VGzvjDXYqNq+o6RYimtkw O6/g== X-Gm-Message-State: ANhLgQ2burVu5S/NUibdrE9u7Hl1hGBFTtT4019M0aA9THqjodDNEnxl UrDn91FV153Fk2qbGr5OJL7PSgexlxnhAqTrXOilm76g X-Google-Smtp-Source: ADFU+vs154uCQiEg1uvEM6J3T9kgjX1vtVEL7xbYY3eyoyuFU+RxbbKKtLjO7LTLXIGm86YKFIKeDazLVivWh5WvKtw= X-Received: by 2002:a5d:8143:: with SMTP id f3mr18279254ioo.12.1583853893580; Tue, 10 Mar 2020 08:24:53 -0700 (PDT) MIME-Version: 1.0 References: <2227A758-3035-4A43-974C-C4461A096DFB@newclarity.net> <854D29ED-C2EA-4201-87EB-CE561F630F37@newclarity.net> In-Reply-To: <854D29ED-C2EA-4201-87EB-CE561F630F37@newclarity.net> Date: Tue, 10 Mar 2020 15:24:42 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000b3ff1405a081b8fd" Subject: Re: [PHP-DEV] [RFC] Attributes v2 From: rowan.collins@gmail.com (Rowan Tommins) --000000000000b3ff1405a081b8fd Content-Type: text/plain; charset="UTF-8" On Tue, 10 Mar 2020 at 15:04, Mike Schinkel wrote: > > I think he meant return type declaration. That's why the question about > > the `use` clause is as well relevant. > Yes, that was a typo on my part, sorry. > But even so, the question is surprising because we have a well established > existing pattern with extends and implements clauses, for example: > > function foo():returntype > extends Parent > implements Interface1, Interface2, Interface2 > attributes Attribute1, Attribute2, Attribute3 {} > > I'm not sure where you're going with that - as far as I know, extends and implements are only valid on classes, and return types are only valid on functions, so there'd never be a mixture in one declaration. Still, you're right that it's perfectly resolvable, it's just an extra consideration to throw into the mix. I do think that particular syntax would get a bit messy with more involved declarations, though: public static function doSomething(Action $what, int $howManyTimes): boolean attributes Memoize, Jit, Log(LogLevel::DEBUG), Autowire(1) { // ... } Maybe rules for whitespace would evolve to let that flow onto multiple lines, but it's not quite clear how the indenting should look; like this maybe? public static function doSomething(Action $what, int $howManyTimes): boolean attributes Memoize, Jit, Log(LogLevel::DEBUG), Autowire(1) { // ... } The current proposed syntax leaves the main declaration as it is now, and visually separates the attributes at the expense of vertical whitespace: << Memoize>> <> <> <> public static function doSomething(Action $what, int $howManyTimes): boolean { // ... } A suggestion that's come up a couple of times is to allow grouping of attributes, so you could flatten it onto one line: <> public static function doSomething(Action $what, int $howManyTimes): boolean { // ... } Or the attributes could be grouped according to some coding standard: <> <> public static function doSomething(Action $what, int $howManyTimes): boolean { // ... } There's plenty of other possibilities we could consider, though - again, see the Python wiki link for a whole range of proposals they had for decorators, and we may be able to find similar lists to learn from for other languages. Regards, -- Rowan Tommins [IMSoP] --000000000000b3ff1405a081b8fd--