Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114489
MIME-Version: 1.0
References: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
 <8k-0GSw3SzLqD94K-w_7CKXwcfl7m7Zf8yqom5f1F_reALxX8HLFd_KkBYO-pQnNDaEyknpdP7KZk9NI-mr-vl-sBzcfmS8HdkgGxRoTmpo=@protonmail.com>
In-Reply-To: <8k-0GSw3SzLqD94K-w_7CKXwcfl7m7Zf8yqom5f1F_reALxX8HLFd_KkBYO-pQnNDaEyknpdP7KZk9NI-mr-vl-sBzcfmS8HdkgGxRoTmpo=@protonmail.com>
Date: Mon, 17 May 2021 01:56:32 +0700
Message-ID: <CAG4FTXwhjd2NS6xWkwaqwm0YTZ+czb=WO=36Zq7moxa=kmjGRw@mail.gmail.com>
To: Trevor Rowbotham <trevor.rowbotham@protonmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ba063b05c2770959"
Subject: Re: [PHP-DEV] [RFC] Property accessors
From: the.liquid.metal@gmail.com (Hendra Gunawan)

--000000000000ba063b05c2770959
Content-Type: text/plain; charset="UTF-8"

Hi internals,
>
> I'd like to present an RFC for property accessors:
>
> https://wiki.php.net/rfc/property_accessors


Hi internals,

I am new here.

Thank you Nikita for this wonderful proposal.

A few days ago, I sent an identical message to this thread but I am not
sure it was sent properly. So I sent it back here. Sorry about this.

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 the engine. 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.

--000000000000ba063b05c2770959--