[RFC] Property write visibility

On Mon, Jun 29, 2020 at 12:42 PM André Rømcke andre.romcke@gmail.com
wrote:

This enables readonly, write-only and immutable like semantics for PHP's
properties.

I agree that there is a use case for it, however I don't think the proposed
syntax public:private is intuitive. Maybe we can come up with something
better?

--
Best regards,
Max Semenik

https://wiki.php.net/rfc/property_write_visibility

I'd like this feature as a stop-gap for accessors.

However, I don't like the syntax at all, I couldn't reasonably vote for
it in its current suggested state. I think it's just too messy.

I'm not sure what the alternative should be though. It seems like the
accessor syntax would be the only long-term clean way.

Mark Randall

Hey André,

This does indeed seem to cut into the traditional property accessors scope.

I'm no longer seeing a reason to have property accessors, since immutable
state (and promotion thereof) is much more relevant to fight bugs and
improve application performance and maintainability.

Therefore, I would endorse re-visiting the RFC at
https://wiki.php.net/rfc/write_once_properties instead.

Máté also linked today (
https://twitter.com/kocsismate90/status/1277625002720968704) that C# 9.0 is
getting init-only properties, which looks similar to the RFC linked above.

Assuming we solve annoyances around cloning, that would be a more sensible
way forward, while property accessors seem to perpetuate the bad practice
of getters and setters, which are the main cause for me having to fire up a
debugger in any environment.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Mon, Jun 29, 2020 at 11:42 AM André Rømcke andre.romcke@gmail.com
wrote:

Good morning Internals,

I'd like to start discussion on a new RFC proposing a way to be able to
(optionally) specify property
write visibility, separate from read:

https://wiki.php.net/rfc/property_write_visibility

This enables readonly, write-only and immutable like semantics for PHP's
properties.

These are the common use cases where users tend to resort to magic methods
or setter/getter
methods. This proposal will as such avoid unnecessary boilerplate, makes
coding easier and more
ergonomic, and in the case of magic method usage improve performance.

Best,
André Rømcke

I'd like to start discussion on a new RFC proposing a way to be able to
(optionally) specify property
write visibility, separate from read:

https://wiki.php.net/rfc/property_write_visibility

This enables readonly, write-only and immutable like semantics for PHP's
properties.

These are the common use cases where users tend to resort to magic methods
or setter/getter
methods. This proposal will as such avoid unnecessary boilerplate, makes
coding easier and more
ergonomic, and in the case of magic method usage improve performance.

Thanks, André,

I really like it. I feel like it perfectly fits the runtime visibility
model of PHP. The RFC could have some words to tell how this would behave
when considering the existing magic accessors. We should also define the
behavior when creating a reference (write access should be granted, isn't
it?) and when unsetting a property.

I'd like to share three more points to the discussion:

The previous RFC(s) shocked on a conflict between purity declarations
(immutable/readonly) and the effective need for mutability in e.g. cloning
operations. My experience in PHP is that keywords are strong guidelines but
should never be hard blockers: PHP is a runtime scripting language and some
of its power and flexibility comes from that, e.g. being able to use
reflection sometime to read/write a property in a "friend" scope. "final"
is the canonical contra-example of an imperative keyword that blocks legit
use cases (e.g. inheritance proxies)

I understand why some ppl want immutable/readonly hard guarantees. I think
those are nice goals, and I also think that they are better solved by
attributes/annotations. These features fit compiled languages. In PHP, they
fit static analyzers. There are great ones already and they do a really
good job.

In other answers, I'm seeing questions about private(isset)/private(unset)
in addition to just read+write dissociation. I'm not sure this makes sense:
once a property is declared, "isset-accessibility" is fully covered by
"read-accessibility". Same for "unset-accessibility": it's included in
"write-accessibility". Clarifying how magic accessors would work in the RFC
should help solve this branch of the discussion.

About accessors, they look like another topic to me. I'm not seeing the
need for accessors at all actually. You might disagree, but my point is:
that's another topic. We don't need to agree on the usefulness of accessors
to decide that this RFC provides actionable value that would benefit the
ecosystem.

Being able to enforce an externally-immutable-but-internally-mutable state
is already a lot of value, I know where I would leverage it immediately.

About the syntax, the proposed one looks quite effective to me. It's new,
we need to get used to it. This should come fast given how simple it is.

TL;DR, I fully support the RFC :)

Nicolas

Good morning Internals,

I'd like to start discussion on a new RFC proposing a way to be able to
(optionally) specify property
write visibility, separate from read:

https://wiki.php.net/rfc/property_write_visibility

Perhaps another option could be to use attributes:

<<ReadOnly>>
public int $id;

Assuming named arguments get accepted as well, we could use optional
arguments to specify special behavior by writing:

<<ReadOnly(protected: True)>>
public int $id;

These optional arguments could also be introduced later using a followup
RFC, after introducing a basic ReadOnly attribute.

This attribute-based approach could be extended later to implement
property accessors. That would provide property accessors similar to how
it is done in Python:

<<Property>>
public function someValue(): int
{
  return $this->someValue;
}

which could then be accessed as:

$instance->someValue

The above accessor method would be the equivalent of:

<<ReadOnly>>
public int $someValue;

That makes the ReadOnly attribute a short hand for the Property
attribute. This short hand is something that Python does not have, by
the way.

Using accessor attributes to create a writable property could look like
this:

<<PropertySetter>>
public function someValue(int $newValue)
{
  $this->someValue = $newValue;
}

Making the property writable only in the protected or private scope
could be done by using the existing mechanism of declaring the accessor
method as protected or private.

So perhaps an attribute-based approach provides a nice alternative path
for gradually improving object ergonomics.

Regards,
Dik Takken

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.

On Mon, Jun 29, 2020 at 11:43 AM André Rømcke andre.romcke@gmail.com
wrote:

Good morning Internals,

I'd like to start discussion on a new RFC proposing a way to be able to
(optionally) specify property
write visibility, separate from read:

https://wiki.php.net/rfc/property_write_visibility

This enables readonly, write-only and immutable like semantics for PHP's
properties.

These are the common use cases where users tend to resort to magic methods
or setter/getter
methods. This proposal will as such avoid unnecessary boilerplate, makes
coding easier and more
ergonomic, and in the case of magic method usage improve performance.

I think this is a good direction to explore, but would recommend delaying
it until PHP 8.1. As the RFC and discussion note, the design space here
overlaps significantly with both readonly/immutability and property
accessors. We should take enough time to consider these
alternatives/extensions as well, to ensure that we don't end up with
multiple distinct and possibly incompatible mechanisms. We don't have that
time before PHP 8.0 feature freeze.

Regards,
Nikita

I'd like to start discussion on a new RFC proposing a way to be able to
(optionally) specify property
write visibility, separate from read:

https://wiki.php.net/rfc/property_write_visibility

From the RFC:
"Attempting to pass a property value outside of allowed writable scope
as a reference, results in an error."

This part could probably do with having some details for it.

Also, any implementation of that rule might need to be checked for
performance issues.

cheers
Dan
Ack

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 deleugyn@gmail.com 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;}.

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

--
Marco Aurélio Deleu