Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118093 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66967 invoked from network); 24 Jun 2022 20:05:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Jun 2022 20:05:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 47D2C1804BD for ; Fri, 24 Jun 2022 14:56:02 -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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS19151 66.111.4.0/24 X-Spam-Virus: No X-Envelope-From: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 24 Jun 2022 14:56:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2AA165C0178 for ; Fri, 24 Jun 2022 17:56:01 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Fri, 24 Jun 2022 17:56:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1656107761; x= 1656194161; bh=Ez9G3Lj68fsPCoLz9xqorWdip1f0PfaI+wjnSVcnLp4=; b=H LOSLO5AD1VAQZulEMVGhmdSNjEva1urjcSxYLr+QGqrhADDD4TFlxzKHTeJPymAJ BdB7NUzBa08Ls2tKj0xUbboYNGMA8dkGEJTC1OuBlKKWIZfOmPLfwxZK9LX/c5vo Oo6zG0FyCPts+eCqTAGTV/ZvCZP09oHQJOwzB8k1tamNJfIjdyHcF3iEdLGYbRY/ Gnzmf4d4FnYv1ENfgk6w02N49MWaeYQwpCsodSX8pieXQ991TsWyjyteMuTwQGSF ACAn8rqzgpC35MiLpF2Dn0pdEuDrtT/EKj7UKlOvXDC6q5pr4ZxkVjLBEQFEDzr0 xFYhrT824Qc01Vbq9Riaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1656107761; x=1656194161; bh=Ez9G3Lj68fsPCoLz9xqorWdip1f0 PfaI+wjnSVcnLp4=; b=cGvCEYlh1AZoF01VqUPqDNn666HtTxXsDcm8qN1cmThM ebKj68S3+rGMo+9BY/Gnqfs+ZIlKd72FSv0VcxYbKeRRx6LJ17BUiZbMGblA0LL2 BZa0xPkXQU3qlzuz0ljIulxyf+9oPdP40hwPnN0BojF2g7eXq6v44oXa0JGklFcU thVWStncS+h3iYxXLmOgEgUHoJw3K+LLu+iFmN8WTaeCtiTHt80xr9FtmIVgVVdO 2cC44/ozHUo0WJ/HwcXuAhqeenH2KnjGY1VQEcvIH/CrfvpqTQ+iySTISXOpOv/N dzkxEXmT/E557/v7KSJbvIrxdZA3Wi7qNefWKNl7GQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegtddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeevheehvdevjeelvdevgfelvefftdejkeelvdekgeeh fffgiedvjefhhfeltdduteenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhi vghlughtvggthhdrtghomh X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id EAC391700077; Fri, 24 Jun 2022 17:56:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7 Mime-Version: 1.0 Message-ID: <6a016333-2be0-4865-b263-29611ecb4c62@www.fastmail.com> In-Reply-To: References: Date: Fri, 24 Jun 2022 16:55:30 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions From: larry@garfieldtech.com ("Larry Garfield") On Fri, Jun 24, 2022, at 11:43 AM, Nicolas Grekas wrote: >> > Hi everyone >> > >> > I'd like to start a discussion on a simple RFC to allow fetching >> > properties in constant expressions. >> > https://wiki.php.net/rfc/fetch_property_in_const_expressions >> > >> > The RFC proposes adding support for fetching properties in constant >> > expressions using the -> operator. I'm looking forward to your >> > feedback. >> > >> > Regards, >> > Ilija >> >> The enum-in-attribute use case came up recently in Symfony. I'm in favor >> and the RFC looks good to me. >> > > Genuine question: > > In the thread about auto-implementing Stringable for string backed enums, > there is extensive argumentation to explain why ppl that use enums this way > are wrong. You mentioned writing a blog post about these reasons Larry, and > Benjamin (/cc) also expressed a similar opinion. > > So my question is: don't these arguments apply here also? Shouldn't we > reject this RFC and tell ppl to use consts instead? If not, why? > > Nicolas A fair question. :-) (Also, I'm working on said blog post literally as we speak.) I'd say for many of the cases where the inability to use ->value has come up (eg, Attributes), a constant would indeed be the better solution. That's what people should probably be doing there. However, while there are clear downsides to letting enums auto-coerce to strings (as discussed elsewhere), I don't really see a downside to this RFC. An enum case's value or name properties are guaranteed constant and readonly, so there's no reason I can see to *not* allow them to be used in a constant, readonly context. That it would allow someone to use SomeEnum::Beep->value in a place where it would probably be better to use SomeConst::Beep instead is a mostly-harmless side effect that doesn't violate any type expectations. And, if anything, the slight clunkiness of the syntax serves as an indicator that maybe you are doing it wrong and should be looking at something else. So this patch is, in my mind, more about fleshing out a gap that fell through the cracks last version that happens to have a side effect of making connecting enums to pre-enum code possible, if a bit clunky. Auto-converting enums to other types is violating the domain model of different types and confusing their type spaces in semi-magical ways. (Also, this is an understanding of the problem space I came to just in this past week, and hadn't fully chewed through when this RFC was first put forward.) --Larry Garfield