Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114298
MIME-Version: 1.0
References: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
 <c4476acc-f25e-4454-9cc5-08162207d36b@www.fastmail.com>
In-Reply-To: <c4476acc-f25e-4454-9cc5-08162207d36b@www.fastmail.com>
Date: Sat, 8 May 2021 08:08:22 +0700
Message-ID: <CAG4FTXz7EMVDkXufYE_A_rVhGyY5hNKe6TiLiRAh13Bp_s=ipg@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e5d3a105c1c72e48"
Subject: Re: [PHP-DEV] [RFC] Property accessors
From: the.liquid.metal@gmail.com (Hendra Gunawan)

--000000000000e5d3a105c1c72e48
Content-Type: text/plain; charset="UTF-8"

 Hi internals,

I am new here.

Let me make a suggestion for this one of mostly asked feature:

    class  MyOldOrdinaryObject {
        public string $prop1 { get use getProp1; set use setProp1; }
        public string $prop2 { get use prefixProp2; set use prop2Sufix; }

        // pre existing methods
        // same function signature with corresponding accessor
        // method name is irrelevant
        public function getProp1(): string {/* ... */}
        public function setProp1(string $val): void {/* ... */}
        public function prefixProp2(): string {/* ... */}
        public function prop2Sufix(string $val): void {/* ... */}
    }

This way:
* without forcing them to use the new ones, users can choose whether to use
old ones or new ones.
* code duplication can be prevented, if we decided to preserve the old ones.
* the accessors are more tidy and readable, if we decided to move out all
multiline accessors.

As far as I understand, the difference between "set" and "guard" is: with
"set", we have freedom and responsibility to allocate a space.
Additionally, we have to choose whether to use "set" or "guard", not both.

It is a sad decision that "guard" has to be eliminated to reduce
complexity. In my opinion, it is valuable that we can write code more
concise than before:

    class  MyOldOrdinaryObject {
        public string $prop1 { get; guard use commonGuard; }
        public string $prop2 { get; guard use commonGuard; }

        // Assuming that prop1 & prop2 have the same validity rules.
        // The visibility is private in order to prevent users accessing it.
        // Due to loss of space allocation and difference of function
signature,
        // this method cannot be used in concert with "set".
        private function commonGuard(): void {/* ... */}
    }

With this capability, the complex accessor in constructor problem can be
solved:

    class MyValueObject {
        public function __construct(
            public string $prop1 { get; private guard use guard1; }
            public string $prop2 { get; private guard use guard2; }
            public string $prop3 { get; private guard use commonGuard; }
            public string $prop4 { get; private guard use commonGuard; }
        ){}

        private function guard1(): void {/* ... */}
        private function guard2(): void {/* ... */}
        private function commonGuard(): void {/* ... */}
    }

I hope that "guard" can be included again.

I don't understand the internals of PHP VM. I think the mechanism of this
is compiler assisted copy-paste (same as traits), but only the function
body and the visibility is overridden based on accessors definition.

Regards,
Hendra Gunawan.


On Sat, May 8, 2021 at 5:16 AM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Tue, May 4, 2021, at 5:33 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > I'd like to present an RFC for property accessors:
> > https://wiki.php.net/rfc/property_accessors
> >
> > Property accessors are like __get() and __set(), but for a single
> property.
> > They also support read-only properties and properties with asymmetric
> > visibility (public read, private write) as a side-effect.
> >
> > The proposal is modeled after C#-style accessors (also used by Swift),
> and
> > syntactically similar to the previous
> > https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 proposal.
> >
> > While I put a lot of effort into both the proposal and the
> implementation,
> > I've grown increasingly uncertain that this is the right direction for us
> > to take. The proposal turned out to be significantly more complex than I
> > originally anticipated (despite reducing the scope to only "get" and
> "set"
> > accessors), and I'm sure there are some interactions I still haven't
> > accounted for. I'm not convinced the value justifies the complexity.
> >
> > So, while I'm putting this up for discussion, it may be that I will not
> > pursue landing it. I think a lot of the practical value of this accessors
> > proposal would be captured by support for read-only (and/or
> private-write)
> > properties. This has been discussed (and declined) in the past, but
> > probably should be revisited.
> >
> > Regards,
> > Nikita
>
> Another question: I skimmed through the PR and its tests, and I didn't see
> any tests around attributes.
>
> How do you envision attributes interacting with accessor-using
> properties?  I suppose there's no change for implicit accessors, but what
> happens for explicit accessors?
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000e5d3a105c1c72e48--