Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109434 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98823 invoked from network); 29 Mar 2020 23:34:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Mar 2020 23:34:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 465D81801FD for ; Sun, 29 Mar 2020 14:59:48 -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 wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 ; Sun, 29 Mar 2020 14:59:48 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 6F6F46A2 for ; Sun, 29 Mar 2020 17:59:47 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Sun, 29 Mar 2020 17:59:47 -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=CbMCLw TECVkurlmdR+dVxM5Q9dCmtGzMwwaSXRA+AdI=; b=SkL0YPYMek/5xFLrG/4vSF motHYt6g0vKqCi4j0YHoeaK9CiSBgWZ8HewK4UCvMl/8/UF7cPAFvkzXU7ghnfiN daY3Vi1zsTHH80UkHp86GwoBhvGEN0TE6Ul2InklSKIVZ+XIk7d2YKEcLaTrWxh5 /YUDTSg5a7hjrQw4qebWuMavMgrv5faUo80yrvhPu0aWtz+8WUOhTC5USjFG4nhB Ykg5N41QILpo2GdxsXNCpNKFL3Oz0oVWHQ9/1+bbxxTKaBjM1yQrK2Dlnky5XQbM 9zr7GcBVPmfTN4wpjm91IhNLH7Rvni101GEP3VG18itNKTm4miPq0lo8mWJ1TO5Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeigedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehl rghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AEA0314200A2; Sun, 29 Mar 2020 17:59:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-ID: In-Reply-To: References: Date: Sun, 29 Mar 2020 16:59:26 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment From: larry@garfieldtech.com ("Larry Garfield") On Sun, Mar 29, 2020, at 3:57 PM, Jakob Givoni wrote: > Hi Rowan, > > On Sun, Mar 29, 2020 at 10:00 AM Rowan Tommins > wrote: > > > > > myObj.with { > > foo = 10 > > bar = foo + 20 > > } > > > > I really like the suggested "with" syntax, - in fact I had > contemplated something like that along the way. > The slight "problem", I think, is that, as you mention, adding a fully > fledged "with" syntax would imply that you could do a lot more than simply > assigning values to properties. > And while I agree that that would be cool, it feels like overkill for the > actual problem COPA is trying to solve. > Do you think a narrow version of "with" syntax could be incorporated into > COPA without causing frustration? Or would it be wise to give it its own > RFC? > > I haven't researched if there have already been RFCs proposing something > along the lines of "with", and as such I have no idea if it has already > been discussed and found problematic. > > > > I'm not sure whether I like this idea or not, but I thought I'd share > > it, because I think COPA as currently proposed is too narrow a use case > > to deserve a special syntax. > > > > I understand and fully agree that COPA is narrow, but I don't really > understand why that's a problem - I proposed it exactly because I felt that > its simplicity is its force. > Low hanging fruit is usually something I would encourage to go after. > I believe it's a trivial implementation that can help in uncountable > situations where you just need to assign values to a predefined data > structure in a single expression. > > I'd really like to hear the arguments against such a cost-benefit > calculation. > > Cheers, > Jakob I went into this in my earlier Object Ergonomics post, but in short, it's quite possible for a solution to be *too* narrow. It becomes useful in too small a subset of cases to justify its added conceptual weight (and contrary to the view of some, "if you don't like it don't use it" is just not a thing when you're working in OSS, because someone is going to use it and you'll inherit that code). A narrow solution can also inadvertently serve to make something too easy that should be done rarely. In this case, the problem with COPA as proposed is that it only works for public properties that are assigned literally. That is, in my experience, a very rare case. Most objects want and need to have private or protected properties for a large variety of reasons, which would make COPA useless. Or it would nudge users toward making more properties public so that they can use the shorter COPA, but in the absence of a readonly keyword, asymmetric visibility, property accessor, or something along those lines that is a net loss as it means more properties become public when they really shouldn't be. In that case, a broader, less narrow solution is superior: Look at the actual pain points generally, find out their common elements, and address those. IMO, the combination of constructor promotion and named parameters would have a much better ROI than a dedicated syntax, it would not suffer from the public properties problem, it would still allow for constructor parameters that are not a 1:1 map to properties, but it would still serve to greatly reduce the amount of typing needed. That is, that approach offers more functionality for roughly the same or less additional syntax. In short, the cost-benefit calculation says this is useful in too narrow a case, and has the potential to encourage bad design in the name of typing less. Other alternatives address that problem space better. --Larry Garfield