Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111949 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 89992 invoked from network); 28 Sep 2020 17:55:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Sep 2020 17:55:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 028741804C3 for ; Mon, 28 Sep 2020 10:06:40 -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-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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, 28 Sep 2020 10:06:38 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id x14so2138361wrl.12 for ; Mon, 28 Sep 2020 10:06:38 -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=oMKPLKJ5CIVdvLIJARW4V1GQwKFjeTx41M32eDvE7lQ=; b=FbPfMEU3HpDsLe929+yZ0pBcxEtdpo0uE2ik1PgIzNCysLE/h9j6DJpw8qs8Ab8PKx lgLhLxFr3sRnrZiZsP9vl4ZfvDucviMYsdwXEAwcBlDgV3jwTNkRQKdNQyXhVUZFFPja N6gB9ust5twYddVU8yDf5w+GrP/QI/+2wsAxrcUUb6XZbMd7FOx7v3CB4684H0q6NVL/ arD0T5u67oZuG4DsGoLOAgkJdoHRbT7spZ7LpMfAt6qotvETvcaPrVRhW5kaJ/COYJFl MJUxd+aA5RWdLa57yWvtmp1LliWLnOL2IfQSXmbUL8AfXdO7Ko9Q/JOShzBci+XRuex0 PD1Q== 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=oMKPLKJ5CIVdvLIJARW4V1GQwKFjeTx41M32eDvE7lQ=; b=CNJSaY050mttgib7Zaq+/i08t/YH/WrlLiplOTYb2FCNeUnsQ+eUjMQqJPtekiUSTi jNVK49Ds4L5qpWz+DQgMcVxcpM9p5GwZc3vpKupxjBCpZXAn1xYhA7KeGkgOn639xhF4 11pQ07XolKgN5jKCrChr2AzTjvILRc2+HxWGOiPDbzwljMyIdPqGV8gRdcMg9uzGckIe woufTxbEodmBRNyrAKTYMIhrp8u0mKk/iI8YJ57aWd4jjssNYmezPk1s51U2DLn/XeXO oSe8aDphaoVRKDjKLs3La/aRKreSeTCr4Rx5BqrpG1H1UWtAGx+Ejck31V4iuJkg2KRK bvpA== X-Gm-Message-State: AOAM533qOof64XgVXyMO/jN/EzEaD9zuTzOSwk2wkXJOmgeg20XkP0z+ P4TBJ5gO7V1XhLRj9r7iLRZfYMX3v1vJIZnWfkflzw== X-Google-Smtp-Source: ABdhPJy173n+b40U950DB2VK3xSCw5814+nsT31UeWY3dpUsdpX3Ysnu+zxAVPAVbivEmO2mvI1Z6XOuClxbTIoRB0M= X-Received: by 2002:a05:6000:7:: with SMTP id h7mr2937366wrx.16.1601312795772; Mon, 28 Sep 2020 10:06:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 28 Sep 2020 19:06:24 +0200 Message-ID: To: Benjamin Morel Cc: Nicolas Grekas , Nikita Popov , PHP internals Content-Type: multipart/alternative; boundary="0000000000005ddb2605b062b042" Subject: Re: [PHP-DEV] Re: Attributes and constructor property promotion From: kontakt@beberlei.de (Benjamin Eberlei) --0000000000005ddb2605b062b042 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2020 at 4:35 PM Benjamin Morel wrote: > On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas > wrote: > >> I assume the 80% case is properties, because attributes did not have >>> docblock annotations yet, that means this use-case isn't even possible = at >>> the moment. Yet annotations on properties are widespread (Doctrine ORM, >>> symfony validator, ...). >>> >> >> I'm 100% with Benjamin here, this is what will be the most useful to me >> also. >> > > To be clear, I don't have a strong opinion against yours, I'm just > pointing out the fact that even though it might be useful, it might also = be > confusing and create yet another WTF moment in PHP for developers. Sure, = it > might make more sense to apply to the property. Sure, so far annotations > weren't possible on parameters. But is that obvious to the average > developer writing the attribute? A few years down the road, DI containers > may have broad support for annotating parameters for injection. Will it > still be obvious then that an attribute on a promoted property applies to > the property only? > > I do agree that applying the attribute to both the property and the > parameter will probably never be useful, though. So, throwing an exceptio= n > and forcing the de-sugaring feels like the most sensible thing to do for = me > in this case! > I haven't checked if this is possible in the code doing the "desugering", but what if we had an attribute on the constructor that could specify where the attributes should apply to? #[AttributePromotion(Attribute::TARGET_PROPERTY)] public function __construct(#[Foo] public string $bar) {} Then we could apply it to both by default, which is what is probably the expected approach, and users could change it to apply only to properties, which is what is the use-case that makes most sense. > > =E2=80=94 Benjamin > --0000000000005ddb2605b062b042--