Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111586 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 80695 invoked from network); 17 Aug 2020 16:20:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Aug 2020 16:20:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 900EC18056B for ; Mon, 17 Aug 2020 08: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_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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, 17 Aug 2020 08:21:35 -0700 (PDT) Received: by mail-wr1-f52.google.com with SMTP id f1so15418438wro.2 for ; Mon, 17 Aug 2020 08:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5wleopGTZJpDOr86MLGjZOKfbiJ0kabMKY1THulScTU=; b=bawYB/eR+Lb1uvUPXbFG/L9n/ZhdokjbcwGbfzy0m2FF9U4GYOrHkHW2VPkGE93tSG 3WUbs/dZEkafk1Ebd0XLDyS/4xFE1TeuXlZAd8527ArZVExnHs5alTg6ArWKURGAjYpU EsKXlp241qFWBPLiSoIkKzEm16bP9VIalry4pCcfpCmbEyW4fY5PON85IxJnOIbRJMZr zO9CIhatSDt5+dWogjrwciCcYtpIg8yyu3TDyUaRdy36eiCBTZDcicg1H2ioRc+XbECl XSrarmJwpkJdfXm+dwPjgqy5paJy+wQPrFxazkAe+EwMrR/8lQg6fnwzXnXVh496JSGu p9sA== 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=5wleopGTZJpDOr86MLGjZOKfbiJ0kabMKY1THulScTU=; b=E2uvJ6NBPGm6bplXozB/bBS1wLleshtsHjaLTgAmlWKe19gzYABWSXbcl3MwPktq8C G4lEpv/m7exxaVJ/j7zSH4xinh+zpc+saaiL2dl1Ql5YE75UxRDPlxQmYKN7++HxSyr5 i//TFyEslj7+dpshkK4j6QTKz19WbRqtqjcYh8D2VUr1iqh5UG6HhQwlfEMNtIfqONcc IPztPnyoqkXxgeUw1jPNsCylEaul723gFvDB/qldfYYEcxdiwMsJW7rL5varRgUuXL7k D0qHB0nOtmBpAbYsXnVILRNUStaeL/9Sdg5Sy1JqQ1j0luYn7Wig2N7qdr5mae04Zq5+ Jh4A== X-Gm-Message-State: AOAM532vxCtF+tdTp9erY7vP+2jCPKPQVSJUJ1o/M6CZrz3qAW8Ptvkf U8NZ9zo2LwpdCY6ToH1RbShtb4pXwcLoAul1irLRww== X-Google-Smtp-Source: ABdhPJx7IorXhsfLzqHuUUSo3IV0R5ftWI+E1kC6jOqoB95GiMZDq57KU+Ix+ZejCrD7AjyTo/mKU7vV1EmZP1cJJeg= X-Received: by 2002:adf:dcc8:: with SMTP id x8mr16805042wrm.16.1597677694496; Mon, 17 Aug 2020 08:21:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 17 Aug 2020 17:21:22 +0200 Message-ID: To: Theodore Brown Cc: Derick Rethans , PHP Developers Mailing List Content-Type: multipart/alternative; boundary="00000000000072783205ad145334" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: kontakt@beberlei.de (Benjamin Eberlei) --00000000000072783205ad145334 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 5: 14 PM Theodore Brown wrote: > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown > wrote: > > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei > wrote: > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown > wrote: > > > > ## Potential Future Benefits of Enclosed Delimiter Syntax? > > > > > > > > The RFC shows an example of a potential "simpler" attribute using a > > > > string instead of a class name. I honestly have no idea what this is > > > > supposed to do or what benefit it would have over normal attributes. > > > > > > > > The concept of attributes being a class name with optional arguments > > > > has been proven over many years by its use in docblock annotations, > > > > and if there was some deficiency in what this syntax allows it seems > > > > like we would have discovered it by now. > > > > > > I agree on just the string, but a closure would make 100% sense for > > > a decorating feature. Javascript and Python "Attributes" work as > > > decorators, i.e. they get called around the decorated function. > > > > > > It is not a completely unrealistic feature to think off: > > > > > > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)] > > > function foo($message) {} > > > > As I understand it JavaScript decorators do not use anonymous > > functions for decorators like this, though. Instead you would make a > > named function and apply it with `@myFunc()` before the decorated > > function or class. > > > > Presumably we could accomplish the same thing in PHP with e.g. an > > `__invoke` method in the attribute class, without complicating the > > attribute syntax itself. > > One other thought on this. I agree that decorators are not a > completely unrealistic future feature. However, it must be noted that > both JavaScript and Python use the `@Attr` syntax for decorators, and > the lack of an end delimiter in no way precludes this usage. > Yes they support decorators with @, but they don't support metadata. With this syntax its either or, because from @Attr only you cannot decide if its a decorator or a metadata attribute. It would not work by detecting __invoke on the Attribute, because the whole architecture of Attributes is based on deferring autoloading until Reflection*::getAttributes(). But when you use decorators, you would need to know this at runtime, so the zend_attribute datastructure would need to know its not an metadata attribute, but a decorator. > The whole point of a decorator is to offer syntax sugar for a common > reusable pattern (pass a function/class to another function which can > add additional information or behavior to it). It's not clear how an > anonymous closure would be useful for this, since it would not allow > reusability, which defeats the purpose. > > So the argument that an end delimiter has "potential future benefits" > still lacks any realistic examples, and is countered by years of > proven usage of the `@Attr` syntax in docblocks and other languages. > > Sincerely, > Theodore --00000000000072783205ad145334--