Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109904 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21620 invoked from network); 29 Apr 2020 09:00:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Apr 2020 09:00:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8B5881804B4 for ; Wed, 29 Apr 2020 00:34:18 -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-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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 ; Wed, 29 Apr 2020 00:34:17 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id w20so1560656ljj.0 for ; Wed, 29 Apr 2020 00:34:17 -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=eQYWvYW8TYNbBx+sPm9u+sb67jmPs2lGnbuamUp7Fbc=; b=OJekY3sNxeUJ0bA5Oa/elKja+kQPClBfvu0xfEPbtNqCMe80vUu0x/hntKsZPvg396 LoYqfC68LrBTnJrYyR/jytEriq4I2U3JcFJ2vIEklSxN6vMNEzZYt1cswcQWhczw/HJ3 Bxn2v4uehfUouY9wgypmiaOiQSLJ5TqY+9HQei052Z8hKm2rxm4FF9AYsD13FyNMs3mj vaHaswMhCtyzs3cNpVFzPoxYuTmDQWCJL0XsqNOU6/P2NQQD9n+f3u6TU/ntgDaEMUrk Uahe6U3hWk/EV7UkB4ORUx+I/iHnkQU4n23Us9Yvs6wMPr8vRjHhq56W3KAuOaOHi2F7 qoEw== 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=eQYWvYW8TYNbBx+sPm9u+sb67jmPs2lGnbuamUp7Fbc=; b=ICrMxdr6XBYISU8j+rc8uglhceA6bkiSgv6Bh4SPqO7u9RRjNJwrC3BdRV2DAA2gxt XGBexLUkhL+S+1cVXrmWaVlM42rujo/rsGXvISCiNt2xJUgeKHJN5fjjKR+fOKkOleTw djb5PRIJW4Xnv7v/Hrups4qIknwl/tdvim6Heda6jk3LcHoT4W+eMVUcAyxexXcEn1n2 +D8Zxx/rPYeOA3PaxjJtL8L6KjcOzrwLv1A0PqrVYvCqtiDZOTYJRyg/W06+T2Ips5cn h2NMb0munnHy1XTw19MXpdBiJ+KSAVqR+O2Q56IChtyioOgVPX7wgSpSw/ff22A9vNif pn/Q== X-Gm-Message-State: AGi0PuY4lW48k9Zr6U1RXrio7VGoUofIHOLvjaExQ5iqiLxdZnQEX5RP j933SpQTE2+CuLs1nk5OGRydV6zn5Rpn8fgdhh0Vli4m X-Google-Smtp-Source: APiQypJxhUPOP4nmlab0b5gamrDuUMxE4Ii95s/5EnEgBUKnhqRD344IjIV6IW72V4adGFQiHdZ+7cZr+XupVOSjJhU= X-Received: by 2002:a05:651c:39b:: with SMTP id e27mr20540570ljp.145.1588145653071; Wed, 29 Apr 2020 00:34:13 -0700 (PDT) MIME-Version: 1.0 References: <76b72148-4b3a-4a63-ab4c-245439a94823@www.fastmail.com> In-Reply-To: <76b72148-4b3a-4a63-ab4c-245439a94823@www.fastmail.com> Date: Wed, 29 Apr 2020 09:33:56 +0200 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="00000000000080c23805a468f9d0" Subject: Re: [PHP-DEV] Re: [RFC] Constructor Property Promotion From: nikita.ppv@gmail.com (Nikita Popov) --00000000000080c23805a468f9d0 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 29, 2020 at 2:05 AM Larry Garfield wrote: > On Tue, Apr 28, 2020, at 10:56 AM, Nicolas Grekas wrote: > > > > > > > I would expect attributes to apply only to the properties on my side. > > > > > > Parameter annotations could be interesting for dependency injection. > > > Symfony currently has some DI magic through parameter names among > > > other things. It might be nice to control these through annotations > > > instead. This would be impossible or involve a lot of hackery and > > > assumptions if the annotations aren't available on the parameters. > > > Alternatively we might make this information available through > > > reflection (like ReflectionParameter::getGeneratedProperty()) so you > > > can look for the annotation there. > > > > > > > Sure, this could be considered. > > > > But this doesn't contradict what I wrote: > > if one uses constructor promotion, the then attributes should only go to > > the properties to me. > > If one wants to add attributes to parameters, then one would need to > > opt-out from constructor promotion. > > > > Nicolas > > I'm inclined to agree with Nicolas. My gut feeling (and I don't have more > data to back it up than that, I admit) is that property annotations will be > more prevalent than parameter annotations, so those should take precedence. > > That said... how many will conflict? In practice, the most common use > case I can see for parameter attributes would be fancy DI configuration for > services... and I don't know that I'd care about attributes on the > properties in that case. Conversely, for properties that have attributes > that will usually be for extended type information, ORM mapping, and stuff > like that. For which... I can't think of what I'd want attributes I'd want > on the parameter itself. > > Perhaps I'm just not creative enough at this hour, but I'm not sure that > "both" is such a problem. It only seems like it would be an issue for > attributes that user-space wanted to enforce on certain cases only; since > attributes are new, a viable answer there is "btw, if you're restricting > your annotation be aware of this double-case and either allow it or don't, > but it's on you to decide what if anything to do." > That's basically my line of thinking as well. I do agree that as things are right now, most likely a property annotation is intended. But that's potentially only an artifact of phpdoc annotations not supporting parameter annotations, so there is no existing ecosystem around them. I think it might be best to apply to "both" and provide an isPromoted() method on both ReflectionParameter and ReflectionProperty. Any code that wishes to validate the allowed positions of an attribute can then skip properties/parameters that report isPromoted() as true, to avoid reporting false positives. Nikita --00000000000080c23805a468f9d0--