Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110791 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60048 invoked from network); 30 Jun 2020 08:59:21 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Jun 2020 08:59:21 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 361B2180088 for ; Tue, 30 Jun 2020 00:48:14 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.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 ; Tue, 30 Jun 2020 00:48:10 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id 17so18574294wmo.1 for ; Tue, 30 Jun 2020 00:48:10 -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=dm5B5nMb9cvcMHd3RG8HTvQ7550C3XUeQBljEO+mV2A=; b=nGDEk4bq84tTpZnbXG1D62hnpXkprw7duHNZ8s9xsXkqQUDJ94cLAKclku52G5TiLS 1FzhZUvdQIafmcVcERALctogWWeiX4E+XmCdjoI3zBABzgWWpS9CNt7za3PJfYgDFqiE tD+53g8Q7hz/jD7stlxEFriLL+lEXhsINi8s59aPRqDRFliLIY+zzFuvNkZ/GMx86VuL 6q9tcWd4ChyJLBYHsRF0KKsvU+8UQzEIvCEHDd4jQQYrhQJuGmhJEozo1rQTU80NUuRk lXNPsPjXyHDsC4WC3M6nOmF2EfHB9nWaD+hudS/DC9JN3Ds3JPcuDKHO3h6NEaE3HQN8 L6tg== 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=dm5B5nMb9cvcMHd3RG8HTvQ7550C3XUeQBljEO+mV2A=; b=EzTRnooiVLHJ+CGX68L3Tor/0+Bxxn/f6gGgnRKU6cPwoQHtatV5UG7TAZI9KgLCPu bkdikZdEaXB2sZoqpT7h9d6nHXR5FH/60CUp6voGCxaBz5eTkFbqBeaf+o/7loP6Q9hE AQADEiEUr3iddlp+aMM5QC3UoX0g0Z1pwIDBBJ5pade+N45TJhmQbYjTZRefdpppTPwW e9xpCbM2BD+hwY152O3ZCXZsTjMgm7ehTM6A9/2EI+1orGY8gQy3icqSeTbfkUTbfEKl z2lexI3siuooatRXeEA+DfcolbnqFmohJfXSAGdMVnnDW1JJg8wGzwClQ3QfI+KCYNjU IFnA== X-Gm-Message-State: AOAM533vJxbFa5VpS6xPL6REqQhMnWDgNB4RmQ3Qm8C8SRjvDaKDv0Je M05WznxLYj+la4tkEKZMShj6/fhWxxCv1D4Fx4MNKP3v X-Google-Smtp-Source: ABdhPJz8roTwoL++Wl4VjSkk5IBooH095KOWL3jA6hgmT4AVSp7/uSbtSh+JD9UtE+6PDQMGpwMiqKZesM7XCIGC69Y= X-Received: by 2002:a1c:238d:: with SMTP id j135mr19537934wmj.46.1593503287256; Tue, 30 Jun 2020 00:48:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 30 Jun 2020 10:47:54 +0300 Message-ID: To: =?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?= Cc: PHP Internals List Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] Property write visibility From: someniatko@gmail.com (someniatko) I do agree with Marco that this is a step in a wrong direction. Our goal should be not ensuring that a prop is not rewritten outside, but rather that it is not re-written at all. It makes no sense to rewrite a property in majority of cases: 1. fields of an DTO - nay. Should be immutable instead. You never change DTO, don't you? 2. injected services (like DB connection or an HTTP client) - nay. Shouldn't ever be overwritten once an object containing them is instantiated. Write-once / immutable is preferred. 3. data fields of an Entity-like object - looks like the only reasonable case. However adding dedicated syntax for this is arguably not much better that what we have now. It is already solvable with standard getX() pattern, or with a single method returning a required chunk of state as DTO. So for me this does only solve the problem of having getters (or dedicated methods) in #3, which is rare enough compared to other code, and is already solvable with syntax existing nowadays already. Introducing the new syntax, however, will have the following downsides: - adding proper immutable / write-once properties to the language will be met with much more resistance: "Why adding immutable if we have private set already!" - this will encourage using them in places where immutability (e.g. via static analysis tool like Psalm) should be used instead (see #1 and #2). - adding more advanced property accessors feature will be also likely met with more resistance.