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 <la...@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
>
>
