Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108923 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69404 invoked from network); 9 Mar 2020 22:04:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Mar 2020 22:04:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 335091804D0 for ; Mon, 9 Mar 2020 13:24:49 -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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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, 9 Mar 2020 13:24:48 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id t11so12914845wrw.5 for ; Mon, 09 Mar 2020 13:24:48 -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=XvIEo7Ug9EqcxaNQOplwK1Ra/55NMhUp0IsXff8yy6w=; b=UoUvwvDyJttzS+QpxB3Ng+XRJpbwt357wphhK4Vjp343183EGLnOSHX4FoItyZ8hvp gMREL3lD/hvA47Wqs/+FGj0xN94W2GQzkv5D2HbEkA0ZEVJrBWhHK84TxD3LBaKDN93Z qFB5E2tyclJgg7wPdih3dcCHJ7tUbvopFl5UyPhC6kofofAQU1HSVAhOZrIrZds2FfiR 1rNc1locKgyHVpyXtBTe9XQbBClwo+hJrcSJXuM6n+dHTbopfzodM2eFiRo1AmaCNCKO 23fMKvpXY6+xCGpk8Qt7jv+M/kiEFWoqQyjThNmHS55Od+6lTAKAOMgPyRHny9OZuvzp oOKw== 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=XvIEo7Ug9EqcxaNQOplwK1Ra/55NMhUp0IsXff8yy6w=; b=SpsR0KGLOCdvnX+EA4jfhq0dgCJA9qt5a4s82ZUe8TPQU/k8ZtnJEbumbwHlW9jp4m KCwmRhijYvnRoKTf1nokhQO57RVnjddUfG1JRbCCQaOfPBpVrvJZMBSWriFCmbTJwmZG odoDvQx61060Lguefx2qWJadeRcxuqHdPgc4jsdHqI5UJ+7NcTDMdl8qE54JNXOIigM7 CXIa/nWFTz7PpG0WX/PESTvWg/h8LIitPmmoGeMhZVrJ1sVMFgTEtjyz/kG9m5HjTcHy gXS0ZBe0iU5yXQt1WsrPXHr5cqo9NBkj9Gfs0O28UxWvaaFO2ZH91AJPfOR8uhJlEqCZ eB3A== X-Gm-Message-State: ANhLgQ3LtCU/RzFWa9CRgLwodTyk4WMW0/S4pQvzY0oSYDVyd1hvR94N tQB/E1tcr/zfJ76+j28gOm8RmWkSGW8TWxM6I4/+P1c5 X-Google-Smtp-Source: ADFU+vuhen0F9hQXJLLhJFdMKB20EE/Llagn6mEGanURIoLI9zCV/TnHqRfScvkDyYaReZz90Fppab2+bFHK18uw+N0= X-Received: by 2002:a5d:4d10:: with SMTP id z16mr24198540wrt.271.1583785482016; Mon, 09 Mar 2020 13:24:42 -0700 (PDT) MIME-Version: 1.0 References: <5e6696b2.1c69fb81.94b65.ce62SMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: <5e6696b2.1c69fb81.94b65.ce62SMTPIN_ADDED_MISSING@mx.google.com> Date: Mon, 9 Mar 2020 21:24:21 +0100 Message-ID: To: Andrea Faulds Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000000e7eab05a071cba8" Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2 From: kontakt@beberlei.de (Benjamin Eberlei) --0000000000000e7eab05a071cba8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2020 at 8:19 PM Andrea Faulds wrote: > Benjamin Eberlei wrote: > > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in > > 2016 with a few changes, incorporating feedback from the mailing list > back > > then and from talking to previous no voters. > > > > The RFC is at https://wiki.php.net/rfc/attributes_v2 > > Hi, > > I have concerns about these two statements in the RFC: > > > The name of an attribute is resolved against the currently active > namespace import scope during compilation. The resolved class names are > then autoloaded to make sure they exist. > > > Consistent with PHP expressions in general, no validation is > performed if the provided attribute arguments are fullfilling the > contract of the attribute class constructor. This would happen only when > accessing attributes as objects in the Reflection API (below). > > These two details are inconsistent with eachother: use of an annotation > triggers an autoload, yet we aren't using the class that is autoloaded > to validate it? This seems quite wasteful: if we have loaded the class, > we might as well use it to check the arguments are correct. Also, why > are we privileging the class existing over the arguments to the class > being correct? If the arguments can be validated at Reflection time, > surely the autoloading can be done then too? Both types of coding > mistake are important. > > It also seems inconsistent with existing PHP behaviour, I think normally > mentioning a class either triggers an immediate autoload and actual > execution/validation (`new`) or it doesn't (a type declaration). This > proposal is a strange half-way house. > > Is this being done to avoid paying the cost of creating the object at > compilation time? Because I think triggering the autoload is going to be > expensive anyway, possibly moreso. > Thinking about how I got to my thought process here, I believe it was something like When compiling new Foo("abcdefg", 1234); then it resolves the class name (does it autoload?) but it wouldn't check if the arguments match until its actually executed. I believe I am wrong to propose autoloading directly at compiling the code is not how PHP does it. It should autoload only during Reflection*::getAttributes(). this is something I haven't implemented in the prototype PR yet, maybe I would have seen the problems. Going to mule this one over and adjust the RFC and this thread with an update. > On a different note, the wording here is syntactically ambiguous. It can > be read as both "if the provided attribute arguments are fullfilling the > contract [=E2=80=A6], then no validation is performed" and "no validation= is > performed as to whether the provided attribute arguments are fullfilling > the contract". I read it as the former the first time, which confused me > for a moment. > Will update to clarify. > > Another thing: > > > Thanks to class name resolving, IDEs or static analysis tools can > perform this validation for the developer. > > Is this referencing the autoloading behaviour? I don't see why that > would be required. (You could also be referring to the fact you use > classes, which IDEs can look for, instead of arbitrary string > attributes, which IDEs can not, which does make sense.) > That is right, an IDE can find this out without the autoloading behavior. This sentence means like you inferred, that because attributes are semantically mapping to class names, that is the reason why IDEs can better validate them in their own static analysis. > > Thanks, > Andrea > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --0000000000000e7eab05a071cba8--