With all possibilities maybe we have:
- public set:private unset:private isset:private get:private
set:private could be readed like "set is private".
Where:
- public is "general visibility" for set, unset, isset and get;
- set: affects write visibility;
- unset: affects unset() visibility;
- isset: affects isset() visibility;
- get: affects read visibility;
In this case, maybe we should think on possibility of usage like:
class A {
get:public $x;
}
That determines that $x is private, except by get.
In counterpart, I do not know if it makes sense for isset mode, because if
we have get:public, and $x is accessible, so it is isset by nature.
Atenciosamente,
David Rodrigues
Em seg., 29 de jun. de 2020 às 12:03, Deleu <[email protected]> escreveu:
> As a user, I would prefer the original proposed syntax `public:private` or
> the Swift syntax `public private(set)` than the alternative syntax `public
> int $x {protected set; protected unset;}`.
>
> On Mon, Jun 29, 2020 at 4:22 PM Mark Randall <[email protected]> wrote:
>
> > On 29/06/2020 15:13, André Rømcke wrote:
> > > Would something closer to Swift be better? If so I expanded the RFC
> with
> > > that syntax option as well:
> >
> > Borrowing from the various accessors RFCs:
> >
> > public int $x {
> > protected set;
> > protected unset;
> > }
> >
> > Then a future RFC can build upon it by adding the override functions
> > while keeping the same base syntax.
> >
> > Mark Randall
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>
> --
> Marco Aurélio Deleu
>
