Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109896 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55316 invoked from network); 29 Apr 2020 01:31:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Apr 2020 01:31:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 324D21804C4 for ; Tue, 28 Apr 2020 17:04:53 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 28 Apr 2020 17:04:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7CC5E8AC for ; Tue, 28 Apr 2020 20:04:51 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Tue, 28 Apr 2020 20:04:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=JGgm2Z aVJ2qpWSJo0Td9VxHbR1WeIabbbiRBV6Iu4Tw=; b=U8kW++qvywRqYv9ryUjRxa pvGchqoWQe11kU8xQTS0TED5YRMHAJqF/pXoZuAN+KZNaXjf7flXqiOoSxfLPcIy vBlRBBJlx/kv1S1iUccKPIueXuufZfodQ+yIfucCY77LJayixtas4jzLabGXZ3oj bw91Exd4s3pvEtzptCmxbVJhWb/mPgPLwbtxOY2FmdpVXtLv0UbUWMqGTbF9sqOE XEdOjel0300URA6hnOnUXHNOjzOGil73g06fg/qznVPfeTbDmalRTjf8sB0DUz/T 3XvzrAE0RM/FzP77ddQyPoySHDn+itMhb+O86w4XikA85N4sMEa8dlsOv1+TiX1A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedvgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgr rhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9652414200A2; Tue, 28 Apr 2020 20:04:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-ID: <76b72148-4b3a-4a63-ab4c-245439a94823@www.fastmail.com> In-Reply-To: References: Date: Tue, 28 Apr 2020 19:04:30 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Re: [RFC] Constructor Property Promotion From: larry@garfieldtech.com ("Larry Garfield") 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." --Larry Garfield