Re: [PHP-DEV] [RFC] Readonly properties

[Mike Schinkel]

> On Jun 29, 2021, at 9:08 AM, Nikita Popov  wrote:
> 
> In any case, I don't want to include changes to cloning in this proposal --
> the topic is related, but also orthogonal to readonly properties.
> Unfortunately, it will not be possible to get cloning changes into PHP 8.1
> anymore, due to feature freeze.
> 
> It's okay to vote against this if cloning is a deal breaker. In that case
> I'll probably either work on cloning before re-proposing this,

I while back I made a suggestion for cloning which seemed to resolve the 
cloning issue in a way that no other proposals do. 

However, no one acknowledged it, so maybe few if any people saw it?  
https://externals.io/message/114729#114747 


Anyway TL;DR, the approach is to allow specifying a closure on clone, binding 
$this to it, and then allow modifications to readonly properties while in that 
context and anything that it calls:

$clone_obj = clone $obj fn() => {
$this->foo = 'new value';
}

Would this not be a viable solution for cloning, for this RFC, or the only you 
work on if this one fails to pass?

-Mike

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre Joye]

On Thu, Jun 10, 2021, 2:32 PM Nikita Popov  wrote:

I'm not sure where you got the strange idea that "readonly" can refer to
> asymmetric visibility. The two syntactic approaches to asymmetric
> visibility that I'm aware of are "{ get; private set; }" in C# and "public
> private(set)" in Swift. Neither use the "readonly" terminology for this
> purpose. Using "readonly" to describe asymmetric visibility is semantically
> incorrect, as such properties are not, in fact, read-only.
>

I listed my refs in the initial reply :)

And some like .net updates their syntax for init only write. I suppose I
see it more as "from the outside of the class" and my personal usages are
like that too.

In any case, good rfc, naming perception is a details, important but a
details for first time users.



> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Thu, Jun 10, 2021 at 3:21 AM Pierre Joye  wrote:

> Good morning Larry,
>
> Thank you. Very good summary, maybe worth adding to the RFC :)
>
> On Wed, Jun 9, 2021 at 11:52 PM Larry Garfield 
> wrote:
>
> >  readonly would be a separate, independent feature/syntax.
>
> Yes, my thought is about self explanatory syntax matching common usage
> of the same syntax/keyword with other languages. In this case,
> readonly, it does not :)
>
> Absolutely not a big deal (one will google that more ;), however I do
> like some "consistency" across languages as we almost all rely on many
> and get used to syntax for very standard operations like this.
>

The usage of "readonly" as proposed follows the commonly accepted
interpretation in other languages (modulo details). Readonly properties
refer to properties that only allow initializing assignments, though what
exactly that means is language dependent (e.g. it can take the form of
"only assignments inside the constructor"). Both C# and TypeScript use
"readonly" in this manner.

I'm not sure where you got the strange idea that "readonly" can refer to
asymmetric visibility. The two syntactic approaches to asymmetric
visibility that I'm aware of are "{ get; private set; }" in C# and "public
private(set)" in Swift. Neither use the "readonly" terminology for this
purpose. Using "readonly" to describe asymmetric visibility is semantically
incorrect, as such properties are not, in fact, read-only.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre Joye]

On Thu, Jun 10, 2021 at 11:08 AM Mike Schinkel  wrote:
>
> Hi Larry,
>
> Thanks for the response.
>
> > On Jun 9, 2021, at 12:51 PM, Larry Garfield 
wrote:
> >
> > Pierre and Mike:
> >
> > "Asymmetric visibility" as we keep referring to it would mean the
"implicit accessors only" version of this:
https://wiki.php.net/rfc/property_accessors
> >
> > That is, it would let you define public/private/protected for get and
set operations on a property separately from each other.
> >
> > There are three key differences between readonly and asymmetric
visibility as described there:
> >
> > * Asymmetric visibility would allow a property to be reassigned
multiple times from within a class, readonly would allow writing to it only
once when it's uninitialized.  Whether one of those is too-tight or
too-loose is a matter of opinion and context.
>
> When I read your statement I first thought you were wrong, but then I
re-read Nikitia's RFC[1] and realized that RFC stated the properties of an
object assigned to a readonly property *could* be updated, but *not* the
readonly property itself.

That's not related but an assignment by "reference" consequence. I think :)


>
> I wonder if I was the only one who read that mistakenly?
>
> Anyway, have either you or Nikita considered making a distinction between
'public readonly' and 'private readonly' such that one could disallow any
changes after initialization and the other could allow changes but only
within the class?

Better formulated than I tried :)

I would like to have the readonly keyword to make a property readonly
outside the class but read/write inside the class, together with
visibility it should cover pretty much all cases (parent class
included).

Init only could be a separate keyword (allows init only, inside the
class or outside the class being defined by the property visibility
attributes, protected, private or public).

I think users, and myself first when I read it, will have a hard time
translating "asymmetric" part of this whole thing (as in, if one
has to go to wikipedia to understand what something does instead of
what it looks like ;) ).

best,

--
Pierre

@pierrejoye

Re: [PHP-DEV] [RFC] Readonly properties

[Mike Schinkel]

Hi Larry,

Thanks for the response.

> On Jun 9, 2021, at 12:51 PM, Larry Garfield  wrote:
> 
> Pierre and Mike:
> 
> "Asymmetric visibility" as we keep referring to it would mean the "implicit 
> accessors only" version of this: https://wiki.php.net/rfc/property_accessors
> 
> That is, it would let you define public/private/protected for get and set 
> operations on a property separately from each other.
> 
> There are three key differences between readonly and asymmetric visibility as 
> described there:
> 
> * Asymmetric visibility would allow a property to be reassigned multiple 
> times from within a class, readonly would allow writing to it only once when 
> it's uninitialized.  Whether one of those is too-tight or too-loose is a 
> matter of opinion and context.

When I read your statement I first thought you were wrong, but then I re-read 
Nikitia's RFC[1] and realized that RFC stated the properties of an object 
assigned to a readonly property *could* be updated, but *not* the readonly 
property itself.

I wonder if I was the only one who read that mistakenly?

Anyway, have either you or Nikita considered making a distinction between 
'public readonly' and 'private readonly' such that one could disallow any 
changes after initialization and the other could allow changes but only within 
the class?

-Mike
[1] https://wiki.php.net/rfc/readonly_properties_v2#proposal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre Joye]

Good morning Larry,

Thank you. Very good summary, maybe worth adding to the RFC :)

On Wed, Jun 9, 2021 at 11:52 PM Larry Garfield  wrote:

>  readonly would be a separate, independent feature/syntax.

Yes, my thought is about self explanatory syntax matching common usage
of the same syntax/keyword with other languages. In this case,
readonly, it does not :)

Absolutely not a big deal (one will google that more ;), however I do
like some "consistency" across languages as we almost all rely on many
and get used to syntax for very standard operations like this.

Best,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Larry Garfield]

On Wed, Jun 9, 2021, at 5:05 AM, Pierre Joye wrote:
> Hi Nikita,
> 
> On Fri, Jun 4, 2021 at 10:19 PM Nikita Popov  wrote:
> >
> > Hi internals,
> >
> > I'd like to open the discussion on readonly properties:
> > https://wiki.php.net/rfc/readonly_properties_v2
> 
> Very good work, thank you :)
> 
> > This proposal is similar to the
> > https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> > previously. One significant difference is that the new RFC limits the scope
> > of initializing assignments. I think a key mistake of the previous RFC was
> > the confusing "write-once" framing, which is both technically correct and
> > quite irrelevant.
> >
> > Please see the rationale section (
> > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> > proposal relates to other RFCs and alternatives.
> 
> About this paragraph in
> https://wiki.php.net/rfc/readonly_properties_v2#rationale:
> 
> " The addition of readonly properties neither precludes nor
> discourages the addition of asymmetric property visibility."
> 
> To me this sentence is the meaning of a readonly property, not an
> immutable property, as in writeable once property, in constructor.
> 
> This RFC is perfect given its goal but the property attribute "readonly".
> 
> How would you define a property only readable from outside the scope
> but writeable inside the scope of its class (->status f.e.)?
> 
> This is PHP and we always have our ways. That being said, the keyword
> "readonly" is really about what is defined as "asymmetric property
> visibility" in many other languages. Rust uses annotation, .net via
> either  readonly and they use an init setter to make it immutable in
> v9 (public DateTime RecordedAt { get; init; }), other like java or
> scala relies on setting a property getters only.
> 
> Given this, I wonder if it would not be easier to have actual per
> property getter/setter as an addition or replacement to the current
> (kind of horrible) get/set($name, $value).  This would all cases in
> one shot, a more complicated shot but much more powerful. For the
> record, I am totally not a fan of the 'manual" get/setMyProperty ;)
> 
> In any case, I would at least put a second thought on the name "readonly".
> 
> ps: sorry if this question has been discussed in previous RFCs,
> pointers appreciated as I did not find it :)
> 
> Best,
> -- 
> Pierre

Pierre and Mike:

"Asymmetric visibility" as we keep referring to it would mean the "implicit 
accessors only" version of this: https://wiki.php.net/rfc/property_accessors

That is, it would let you define public/private/protected for get and set 
operations on a property separately from each other.

There are three key differences between readonly and asymmetric visibility as 
described there:

* Asymmetric visibility would allow a property to be reassigned multiple times 
from within a class, readonly would allow writing to it only once when it's 
uninitialized.  Whether one of those is too-tight or too-loose is a matter of 
opinion and context.

* Asymmetric visibility is deliberately a syntax that is forward-compatible 
with explicit accessor methods in the future.  readonly would be a separate, 
independent feature/syntax.

* Asymmetric visibility, IMO, is a stand-alone useful feature.  readonly would 
be most useful if combined with a separate clone-with operator (discussed 
elsewhere).  Whether readonly is useful enough on its own without that to 
justify its passage without a clone-with RFC also under discussion is an open 
question, and largely what we've been debating.

Both approaches would eliminate *most* uses of __get/__set, which I think 
everyone agrees is a win.

(Nikita, I hope I represented that accurately.)

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre Joye]

Hi Nikita,

On Fri, Jun 4, 2021 at 10:19 PM Nikita Popov  wrote:
>
> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2

Very good work, thank you :)

> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.

About this paragraph in
https://wiki.php.net/rfc/readonly_properties_v2#rationale:

" The addition of readonly properties neither precludes nor
discourages the addition of asymmetric property visibility."

To me this sentence is the meaning of a readonly property, not an
immutable property, as in writeable once property, in constructor.

This RFC is perfect given its goal but the property attribute "readonly".

How would you define a property only readable from outside the scope
but writeable inside the scope of its class (->status f.e.)?

This is PHP and we always have our ways. That being said, the keyword
"readonly" is really about what is defined as "asymmetric property
visibility" in many other languages. Rust uses annotation, .net via
either  readonly and they use an init setter to make it immutable in
v9 (public DateTime RecordedAt { get; init; }), other like java or
scala relies on setting a property getters only.

Given this, I wonder if it would not be easier to have actual per
property getter/setter as an addition or replacement to the current
(kind of horrible) get/set($name, $value).  This would all cases in
one shot, a more complicated shot but much more powerful. For the
record, I am totally not a fan of the 'manual" get/setMyProperty ;)

In any case, I would at least put a second thought on the name "readonly".

ps: sorry if this question has been discussed in previous RFCs,
pointers appreciated as I did not find it :)

Best,
-- 
Pierre

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Mike Schinkel]

> On Jun 8, 2021, at 5:18 AM, Nikita Popov  wrote:
> 
> Well, I think we can get an approximation like this:
> 
> https://beta.grep.app/search?q=%7B%20get%3B%20private%20set%3B%20%7D[lang][0]=C%23
>  
> 
> { get; private set; } 74,281 results
> https://beta.grep.app/search?q=%7B%20get%3B%20%7D[lang][0]=C%23 
>  {
> get; } 156,304 results
> https://beta.grep.app/search?q=readonly[lang][0]=C%23 
>  readonly
> 409,585 results
> 
> Note that the "{ get; }" part includes both readonly properties and
> get-only abstract properties, so that one is an overestimate. Using
> variants like \{\s+get;\s+private set;\s+\} doesn't change the results
> materially.
> 
> Unless my methodology is completely borked, the ratio of readonly to
> asymmetric visibility seems to be something like 4:1 even as a conservative
> estimate.

When you two are speaking of "asymmetric visibility," are you speaking of this 
RFC[1], this one[2], one I am not mentioning, or one that does not exist yet?

If you are referring to [1] there is more to asymmetric visibility than what C# 
would call "auto-implemented properties[3]."  

If we search for `get {` we find 266,859 occurrences and another 5765 for `{ 
set{`. I assume `readonly` would not address either of these?

https://beta.grep.app/search?current=2=get%5Cs%2A%5C%7B=true[lang][0]=C%23
 

https://beta.grep.app/search?q=%5C%7B%5Cs%2Aset%5Cs%2A%5C%7B=true=e[lang][0]=C%23
 

 


-Mike
[1] https://wiki.php.net/rfc/property_accessors 

[2] https://wiki.php.net/rfc/property_write_visibility 
 
[3] 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties
 


P.S. You also over-counted `readonly` by 44k. If you go with case-sensitive for 
"readonly" you only get 365k. Seems they like using "ReadOnly" as part of 
symbol names.
https://beta.grep.app/search?q=readonly=true[lang][0]=C%23 


P.P.S. I'm not taking a position pro- or con- the readonly RFC, just wanting to 
clarify the stats used by others to evaluate.

Re: [PHP-DEV] [RFC] Readonly properties

[Larry Garfield]

On Tue, Jun 8, 2021, at 4:18 AM, Nikita Popov wrote:

> > (Like, for example, if one had a readonly property but wanted to convert
> > it to a custom accessor property... what are the subtle knock on effects
> > they have to account for, then?  There are almost certainly more of them
> > than if switching a property from implicit accessors to explicit accessors,
> > although off hand I don't know what they would all be.)
> >
> > > I think this is a legitimate concern to have, but (under the assumption
> > > that we can have only one) it's not easy to say which would be
> > preferable.
> > > Yes, asymmetric visibility is more widely applicable, but at the same
> > time
> > > I would expect most applications to be bonafide readonly properties. So
> > > while asymmetric visibility is more widely applicable, it's also
> > imprecise
> > > for the majority use case. Which is better? Of course, my assumption here
> > > could also be wrong.
> >
> > As above, I'd love to get some actual data from the C# community on this.
> > Lacking that, we're all just guessing.>
> 
> 
> Well, I think we can get an approximation like this:
> 
> https://beta.grep.app/search?q=%7B%20get%3B%20private%20set%3B%20%7D[lang][0]=C%23
> { get; private set; } 74,281 results
> https://beta.grep.app/search?q=%7B%20get%3B%20%7D[lang][0]=C%23 {
> get; } 156,304 results
> https://beta.grep.app/search?q=readonly[lang][0]=C%23 readonly
> 409,585 results
> 
> Note that the "{ get; }" part includes both readonly properties and
> get-only abstract properties, so that one is an overestimate. Using
> variants like \{\s+get;\s+private set;\s+\} doesn't change the results
> materially.
> 
> Unless my methodology is completely borked, the ratio of readonly to
> asymmetric visibility seems to be something like 4:1 even as a conservative
> estimate.
> 
> Regards,
> Nikita

Interesting.  I have no particular grounds to challenge your methodology, so 
I'll accept that C# seems to use readonly much more than asymmetric 
visibility/accessors.  

Does C# have a clone-with or equivalent?  Even with readonly being useful, I 
think it's only half the answer without a clean evolvability mechanism beyond 
"re-type all the fields by hand."  CPP removed a ton of that boilerplate, and 
I'd hate to bring it back.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Mon, Jun 7, 2021 at 4:09 PM Larry Garfield 
wrote:

> On Mon, Jun 7, 2021, at 4:06 AM, Nikita Popov wrote:
> > On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield 
> > wrote:
>
> > > Thank you for the detailed analysis in the rationale section.  I am,
> > > however, still skeptical of this approach, for a couple of reasons.
> > >
> > > 1. This does appear to address the "leakage" problem I noted in my
> earlier
> > > analysis around the start of the year, when considering the writeonce
> > > proposal[1][2].  That's great to see.
> > >
> > > 2. It doesn't address the larger question of cloning, however.  The
> answer
> > > for now seems "maybe we'll get clone-with at some point", which would
> be a
> > > way around it, but there is no active RFC for that right now.  I'm
> > > obviously very in favor of RFCs that complement each other to give more
> > > than the sum of their parts, but those RFCs need to be at least on the
> > > horizon to actually come together.  Right now that looks like it won't
> > > happen this cycle.  Absent clone-with, readonly would be effectively
> > > unusable in any evolvable object of any non-trivial complexity.
> >
> >
> > Compared to the general area of applicability of readonly properties, the
> > cases that require clone-with are rare. It's the intersection of
> > "not-really-immutable objects using wither evolution" and "has so many
> > properties that passing them to the constructor is infeasible". While
> this
> > intersection does include a couple of prominent examples, they are by no
> > means numerous. While it may be a problem worth solving, I *personally*
> > don't consider it neither particularly important nor time critical.
> >
> > For what it's worth, I believe Mate wants to work on clone-with once this
> > RFC passes -- while there is no RFC for that, there is already an
> > implementation, though from a cursory look it would require some
> > adjustments to actually work with readonly properties.
>
> I look forward to it.
>
> I don't think the use cases for non-trivial structs (where a withX()
> method can just return new static(list all properties here) ) are as few as
> you think.  One difficulty in determining that is that, if they are made
> easier/more robust (via any of the mechanisms under discussion), their
> usage is likely to increase.  That's a good thing, and a benefit of all of
> these pieces floating around, but it does make it harder to gauge the
> net-use of any particular feature.  I prefer to err on the side of enabling
> more flexibility and power rather than less.
>
> > > It also wouldn't work with objects that need properties that are not
> > > constructor arguments, such as PSR-7 type objects.  That's a no in my
> book.
> > >
> >
> > I don't understand what you mean here. Why would properties that are not
> > constructor arguments be a problem?
>
> Without clone-with, if you wanted a with-er method, it would necessarily
> look like this:
>
> class Point {
>   public function __construct(
> public readonly int $x,
> public readonly int $y,
> public readonly int $z,
>   ) {}
>
>   public function withX(int $newX) {
> return new static($newX, $this->y, $this->z);
>   }
> }
>
> That is, you're populating the entire property set via the constructor.
> In some cases that's fine; the larger the object, though, the more
> needlessly verbose redundancy that has.
>
> Now let's add a "rendered" flag property, that is public readonly bool.
> (Maybe not the best example; it's before 9 am and I'm trying to think on
> the fly here.)  It's not in the constructor, but for later processing.  It
> would get set as a side effect of some other method, to indicate the point
> has already been drawn.  Now make a new version of the object with a
> different Z.  What do you do with $rendered?
>
> > > 3. As noted in my previous analysis, even with clone-with, asymmetric
> > > visibility results in a nicer syntax when evolving objects that have
> any
> > > complexity to them.  (See the examples in [2].)
> > >
> >
> > I tend to agree. And I am not opposed to having asymmetric visibility as
> > well. For example, C# does both, and I think both do have value.
> "readonly"
> > is a very strong signal to the reader. Asymmetric visibility is not.
> > Asymmetric visibility (without proper readonly support) could mean that
> the
> > property is actually readonly, or it could mean that it's exactly what it
> > says on the tin: The property is internally mutable. I don't think these
> > two concepts should be conflated, though they certainly have overlap.
>
> I think this is the crux of the disagreement.  There's a large swath of
> cases that could be well-handled by either.  I feel the cases that are only
> or better handled by asymmetric visibility is larger than the cases that
> are only or better handled by readonly.  As noted above, I don't know that
> either of us have any data with which to determine which is actually the
> case.
>
> (Maybe someone with more 

Re: [PHP-DEV] [RFC] Readonly properties

[Larry Garfield]

On Mon, Jun 7, 2021, at 4:06 AM, Nikita Popov wrote:
> On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield 
> wrote:

> > Thank you for the detailed analysis in the rationale section.  I am,
> > however, still skeptical of this approach, for a couple of reasons.
> >
> > 1. This does appear to address the "leakage" problem I noted in my earlier
> > analysis around the start of the year, when considering the writeonce
> > proposal[1][2].  That's great to see.
> >
> > 2. It doesn't address the larger question of cloning, however.  The answer
> > for now seems "maybe we'll get clone-with at some point", which would be a
> > way around it, but there is no active RFC for that right now.  I'm
> > obviously very in favor of RFCs that complement each other to give more
> > than the sum of their parts, but those RFCs need to be at least on the
> > horizon to actually come together.  Right now that looks like it won't
> > happen this cycle.  Absent clone-with, readonly would be effectively
> > unusable in any evolvable object of any non-trivial complexity.
> 
> 
> Compared to the general area of applicability of readonly properties, the
> cases that require clone-with are rare. It's the intersection of
> "not-really-immutable objects using wither evolution" and "has so many
> properties that passing them to the constructor is infeasible". While this
> intersection does include a couple of prominent examples, they are by no
> means numerous. While it may be a problem worth solving, I *personally*
> don't consider it neither particularly important nor time critical.
> 
> For what it's worth, I believe Mate wants to work on clone-with once this
> RFC passes -- while there is no RFC for that, there is already an
> implementation, though from a cursory look it would require some
> adjustments to actually work with readonly properties.

I look forward to it.

I don't think the use cases for non-trivial structs (where a withX() method can 
just return new static(list all properties here) ) are as few as you think.  
One difficulty in determining that is that, if they are made easier/more robust 
(via any of the mechanisms under discussion), their usage is likely to 
increase.  That's a good thing, and a benefit of all of these pieces floating 
around, but it does make it harder to gauge the net-use of any particular 
feature.  I prefer to err on the side of enabling more flexibility and power 
rather than less.

> > It also wouldn't work with objects that need properties that are not
> > constructor arguments, such as PSR-7 type objects.  That's a no in my book.
> >
> 
> I don't understand what you mean here. Why would properties that are not
> constructor arguments be a problem?

Without clone-with, if you wanted a with-er method, it would necessarily look 
like this:

class Point {
  public function __construct(
public readonly int $x, 
public readonly int $y, 
public readonly int $z,
  ) {}

  public function withX(int $newX) {
return new static($newX, $this->y, $this->z);
  }
}

That is, you're populating the entire property set via the constructor.  In 
some cases that's fine; the larger the object, though, the more needlessly 
verbose redundancy that has.

Now let's add a "rendered" flag property, that is public readonly bool.  (Maybe 
not the best example; it's before 9 am and I'm trying to think on the fly 
here.)  It's not in the constructor, but for later processing.  It would get 
set as a side effect of some other method, to indicate the point has already 
been drawn.  Now make a new version of the object with a different Z.  What do 
you do with $rendered?

> > 3. As noted in my previous analysis, even with clone-with, asymmetric
> > visibility results in a nicer syntax when evolving objects that have any
> > complexity to them.  (See the examples in [2].)
> >
> 
> I tend to agree. And I am not opposed to having asymmetric visibility as
> well. For example, C# does both, and I think both do have value. "readonly"
> is a very strong signal to the reader. Asymmetric visibility is not.
> Asymmetric visibility (without proper readonly support) could mean that the
> property is actually readonly, or it could mean that it's exactly what it
> says on the tin: The property is internally mutable. I don't think these
> two concepts should be conflated, though they certainly have overlap.

I think this is the crux of the disagreement.  There's a large swath of cases 
that could be well-handled by either.  I feel the cases that are only or better 
handled by asymmetric visibility is larger than the cases that are only or 
better handled by readonly.  As noted above, I don't know that either of us 
have any data with which to determine which is actually the case.

(Maybe someone with more C# experience can speak to that?  What's typical 
there, where both mechanisms are available?)

> > 5. I would have to experiment a bit with hydration, as others have noted,
> > because unconventional object construction 

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield 
wrote:

> On Fri, Jun 4, 2021, at 10:19 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > I'd like to open the discussion on readonly properties:
> > https://wiki.php.net/rfc/readonly_properties_v2
> >
> > This proposal is similar to the
> > https://wiki.php.net/rfc/write_once_properties RFC that has been
> declined
> > previously. One significant difference is that the new RFC limits the
> scope
> > of initializing assignments. I think a key mistake of the previous RFC
> was
> > the confusing "write-once" framing, which is both technically correct and
> > quite irrelevant.
> >
> > Please see the rationale section (
> > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> > proposal relates to other RFCs and alternatives.
> >
> > Regards,
> > Nikita
>
> Thank you for the detailed analysis in the rationale section.  I am,
> however, still skeptical of this approach, for a couple of reasons.
>
> 1. This does appear to address the "leakage" problem I noted in my earlier
> analysis around the start of the year, when considering the writeonce
> proposal[1][2].  That's great to see.
>
> 2. It doesn't address the larger question of cloning, however.  The answer
> for now seems "maybe we'll get clone-with at some point", which would be a
> way around it, but there is no active RFC for that right now.  I'm
> obviously very in favor of RFCs that complement each other to give more
> than the sum of their parts, but those RFCs need to be at least on the
> horizon to actually come together.  Right now that looks like it won't
> happen this cycle.  Absent clone-with, readonly would be effectively
> unusable in any evolvable object of any non-trivial complexity.


Compared to the general area of applicability of readonly properties, the
cases that require clone-with are rare. It's the intersection of
"not-really-immutable objects using wither evolution" and "has so many
properties that passing them to the constructor is infeasible". While this
intersection does include a couple of prominent examples, they are by no
means numerous. While it may be a problem worth solving, I *personally*
don't consider it neither particularly important nor time critical.

For what it's worth, I believe Mate wants to work on clone-with once this
RFC passes -- while there is no RFC for that, there is already an
implementation, though from a cursory look it would require some
adjustments to actually work with readonly properties.


> It also wouldn't work with objects that need properties that are not
> constructor arguments, such as PSR-7 type objects.  That's a no in my book.
>

I don't understand what you mean here. Why would properties that are not
constructor arguments be a problem?


> 3. As noted in my previous analysis, even with clone-with, asymmetric
> visibility results in a nicer syntax when evolving objects that have any
> complexity to them.  (See the examples in [2].)
>

I tend to agree. And I am not opposed to having asymmetric visibility as
well. For example, C# does both, and I think both do have value. "readonly"
is a very strong signal to the reader. Asymmetric visibility is not.
Asymmetric visibility (without proper readonly support) could mean that the
property is actually readonly, or it could mean that it's exactly what it
says on the tin: The property is internally mutable. I don't think these
two concepts should be conflated, though they certainly have overlap.


> 4. One detail left out of the rationale section is how much of a
> performance difference there is between readonly and implicit-accessors.
> It says the latter still has a performance hit, but not how much.  How
> significant is it?  If it's tiny,  then frankly the biggest argument for
> readonly goes away, since implicit-accessors gives us 98% the same
> functionality in a more forward-compatible way without the cloning issues.
> If it's twice as slow, then having a separate keyword for a common case
> makes sense.
>

The performance difference shouldn't be large, maybe 10-15%. I don't
consider performance a big deciding factor here. When comparing to
accessors the relevant difference I see is that readonly properties cover a
large use case at a small fraction of language complexity.


> 5. I would have to experiment a bit with hydration, as others have noted,
> because unconventional object construction mechanisms are a critically
> important workflow.  The RFC even notes in passing that serialization is
> possibly made complicated.  Just how complicated?  There's no mention of
> __deserialize() and how it would interact, but cases like that need to be
> very clearly handled and documented.
>

The RFC notes in passing that *if* readonly default values were allowed, it
could have impact on userland deserialization. As-is, I believe the
proposal doesn't present any problem for userland hydrators or
deserializers, or PHP's own unserialization mechanisms. This should get
mentioned in the 

Re: [PHP-DEV] [RFC] Readonly properties

[Mike Schinkel]

> On Jun 5, 2021, at 12:51 PM, Larry Garfield  wrote:
> 
> On Fri, Jun 4, 2021, at 10:19 AM, Nikita Popov wrote:
>> Hi internals,
>> 
>> I'd like to open the discussion on readonly properties:
>> https://wiki.php.net/rfc/readonly_properties_v2
>> 
>> This proposal is similar to the
>> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
>> previously. One significant difference is that the new RFC limits the scope
>> of initializing assignments. I think a key mistake of the previous RFC was
>> the confusing "write-once" framing, which is both technically correct and
>> quite irrelevant.
>> 
>> Please see the rationale section (
>> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
>> proposal relates to other RFCs and alternatives.
>> 
>> Regards,
>> Nikita
> 
> Thank you for the detailed analysis in the rationale section.  I am, however, 
> still skeptical of this approach, for a couple of reasons.
> 
> 1. This does appear to address the "leakage" problem I noted in my earlier 
> analysis around the start of the year, when considering the writeonce 
> proposal[1][2].  That's great to see.
> 
> 2. It doesn't address the larger question of cloning, however.  The answer 
> for now seems "maybe we'll get clone-with at some point", which would be a 
> way around it, but there is no active RFC for that right now.  I'm obviously 
> very in favor of RFCs that complement each other to give more than the sum of 
> their parts, but those RFCs need to be at least on the horizon to actually 
> come together.  Right now that looks like it won't happen this cycle.  Absent 
> clone-with, readonly would be effectively unusable in any evolvable object of 
> any non-trivial complexity.  It also wouldn't work with objects that need 
> properties that are not constructor arguments, such as PSR-7 type objects.  
> That's a no in my book.

Larry,

To address the cloning objection to raise to Nikita's RFC there is one solution 
you did not mention in your blog post[1. Rather than your clone-with using a 
syntax that does not exist anywhere else[2] in PHP we could instead use one 
similar to your preferred "clone-with" approach where a closure could be run in 
an internal context. This closure would give the best of both your clone-with 
and of __clone() approaches. Applying this approach to your example in [3] 
gives us:

$r6 = clone $r5 with function($obj) {
   $obj->uri = new Uri('https://python.org/');
   $obj->headers = ['host' => 'http://java.com/'];
   $obj->version = 'the old one';
};

If PHP Internals were to approve the "Auto-capturing multi-statement closures" 
RFC[4] we could also have auto-capture in a place where it would be likely 
common:

$uri = new Uri('https://python.org/');
$headers = [host => 'http://java.com/'];
$version = 'the old one';
$r6 = clone $r5 with fn($obj) {
   $obj->uri = $uri;
   $obj->headers = $headers;
   $obj->version = $version;
};

Another improvement, which I don't know if it is possible or even advisable, is 
if the closure could have automatic access to a $this variable for the instance 
of the cloned object then it becomes even simpler:

$uri = new Uri('https://python.org/');
$headers = [host: 'http://java.com/'];
$version = 'the old one';
$r6 = clone $r5 with fn() {
   $this->uri = $uri;
   $this->headers = $headers;
   $this->version = $version;
};

Interestingly, using your example[2] again, if we were to adopt the same syntax 
for `new` statements we could obviate the need for tedious and verbose "wither" 
methods as well as the numerous internal clones and throwaway variables needed 
with withers called immediately after instantiation. 

For example:

$r2 = new Request() with fn() {
   $this->method = 'POST';
   $this->uri = new Uri('https://php.net/');
   $this->protocolVersion = '2.0';
   $this->header = [ 'cache' => 'none' ];
};

Lastly, you proposed "with" as your keyword to identify the initialization 
values which I assume you picked it because of the "wither" method pattern, and 
my examples above followed suit. 

However, given `with` is not currently a reserved word in PHP and using a 
closure inherently provides an existing keyword, PHP could leverage `function` 
and/or `fn` to indicate "with." (Note the following example do not include the 
two (2) enhancements mentioned above using fn and $this):

$r6 = clone $r5 function($obj) {...};

-Mike

[1] https://peakd.com/hive-168588/@crell/object-properties-and-immutability 
 

[2] Even though I would very much like to see that syntax become a general 
purpose syntax for object instantiation, I think it would not be good to use it 
unless it were fully fleshed out for much greater utility.

[3] https://peakd.com/hive-168588/@crell/object-properties-part-2-examples 


[4] https://wiki.php.net/rfc/auto-capture-closure 

Re: [PHP-DEV] [RFC] Readonly properties

[Larry Garfield]

On Fri, Jun 4, 2021, at 10:19 AM, Nikita Popov wrote:
> Hi internals,
> 
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
> 
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
> 
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
> 
> Regards,
> Nikita

Thank you for the detailed analysis in the rationale section.  I am, however, 
still skeptical of this approach, for a couple of reasons.

1. This does appear to address the "leakage" problem I noted in my earlier 
analysis around the start of the year, when considering the writeonce 
proposal[1][2].  That's great to see.

2. It doesn't address the larger question of cloning, however.  The answer for 
now seems "maybe we'll get clone-with at some point", which would be a way 
around it, but there is no active RFC for that right now.  I'm obviously very 
in favor of RFCs that complement each other to give more than the sum of their 
parts, but those RFCs need to be at least on the horizon to actually come 
together.  Right now that looks like it won't happen this cycle.  Absent 
clone-with, readonly would be effectively unusable in any evolvable object of 
any non-trivial complexity.  It also wouldn't work with objects that need 
properties that are not constructor arguments, such as PSR-7 type objects.  
That's a no in my book.

3. As noted in my previous analysis, even with clone-with, asymmetric 
visibility results in a nicer syntax when evolving objects that have any 
complexity to them.  (See the examples in [2].)

4. One detail left out of the rationale section is how much of a performance 
difference there is between readonly and implicit-accessors.  It says the 
latter still has a performance hit, but not how much.  How significant is it?  
If it's tiny,  then frankly the biggest argument for readonly goes away, since 
implicit-accessors gives us 98% the same functionality in a more 
forward-compatible way without the cloning issues.  If it's twice as slow, then 
having a separate keyword for a common case makes sense.

5. I would have to experiment a bit with hydration, as others have noted, 
because unconventional object construction mechanisms are a critically 
important workflow.  The RFC even notes in passing that serialization is 
possibly made complicated.  Just how complicated?  There's no mention of 
__deserialize() and how it would interact, but cases like that need to be very 
clearly handled and documented.

6. I'm OK with the approach to constructor promotion and default values.  That 
seems reasonable in context, especially if combined with 
New-in-initializers[3], which I am hoping you plan to finish this cycle. :-)

7. Though, it just occurred to me, this may result in issues around optional 
values.  

class URL {
  public function __construct(
public readonly string $scheme = 'https', 
public readonly string $domain = '', 
public readonly int $port = '443',
public readonly string $path = '',
  ) {}
}

Now, if you want to hydrate the object externally, you need to ensure those 
properties are not set by the constructor.  However, a promoted value is always 
set by the constructor; either it has a default or it is required.  From 
previous replies it sounds like the workaround for that is reflection and 
newWithoutConstructor(), but I'm not sure how I feel about that, because that 
would also then preclude any *other* logic in the constructor, as that would 
also get skipped.  Perhaps this isn't as big of an issue as I think it is, and 
if so I'd love to hear why, but it makes me concerned.

8. Although the RFC says it does not preclude accessors or explicit asymmetric 
visibility in the future, and I absolutely believe that Nikita is genuine about 
that, I am still concerned that should more robust proposals come forward 
later, it will be met with "we don't need another still-fancier syntax here, 
readonly is good enough."  It's good to know that C# manages to have both, but 
that doesn't mean the same logic would apply in PHP, or to PHP voters, 
specifically.

9. I know that the variance for properties in child classes was a source of 
discussion, and the end result seems to be that readonly-ness is invariant.  
However, that precludes having an easy way to have both a mutable and immutable 
version of a class, easily.  (If you wanted to have, say, a read-only class 
most of the time for safety, but for writing you use an alternate "open" 
version that can be updated and then persisted to the database.)  That's a 
style I've experimented with 

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Sat, Jun 5, 2021 at 4:28 PM Benjamin Eberlei  wrote:

>
>
> On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov  wrote:
>
>> Hi internals,
>>
>> I'd like to open the discussion on readonly properties:
>> https://wiki.php.net/rfc/readonly_properties_v2
>>
>> This proposal is similar to the
>> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
>> previously. One significant difference is that the new RFC limits the
>> scope
>> of initializing assignments. I think a key mistake of the previous RFC was
>> the confusing "write-once" framing, which is both technically correct and
>> quite irrelevant.
>>
>> Please see the rationale section (
>> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
>> proposal relates to other RFCs and alternatives.
>>
>
> I have a question about Reflection support, the RFC states:
>
> > ReflectionProperty::setValue() can bypass the requirement that
> initialization occurs from the scope where the property has been declared.
> However, reflection cannot modify a readonly property that has already been
> initialized.
>
> Is there a reason why this is not possible? I am thinking about ORMs or
> Deserializers here where a pattern would be:
>
> class MyDataObject
> {
> public function __construct(
> public readonly $foo
> ) {}
> }
>
> $dataObject = $reflectionClass->newInstanceWithoutConstructor();
> $dataObject->getProperty('foo')->setValue($row['value']);
>

This example is compatible with the proposal. Calling
newInstanceWithoutConstructor() leaves the property uninitialized, and you
can initialize it through reflection (or closure rebinding) from any scope.
Hydration and deserialization only requires the ability to initialize, not
to change the value of properties past initialization.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Readonly properties

[Benjamin Eberlei]

On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>

I have a question about Reflection support, the RFC states:

> ReflectionProperty::setValue() can bypass the requirement that
initialization occurs from the scope where the property has been declared.
However, reflection cannot modify a readonly property that has already been
initialized.

Is there a reason why this is not possible? I am thinking about ORMs or
Deserializers here where a pattern would be:

class MyDataObject
{
public function __construct(
public readonly $foo
) {}
}

$dataObject = $reflectionClass->newInstanceWithoutConstructor();
$dataObject->getProperty('foo')->setValue($row['value']);


>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Readonly properties

[Benjamin Eberlei]

On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>

I have a question about Reflection support, the RFC states:

> ReflectionProperty::setValue() can bypass the requirement that
initialization occurs from the scope where the property has been declared.
However, reflection cannot modify a readonly property that has already been
initialized.

Is there a reason why this is not possible? I am thinking about ORMs or
Deserializers here where a pattern would be:

class MyDataObject
{
public function __construct(
public readonly $foo
) {}
}

$dataObject = $reflectionClass->newInstanceWithoutConstructor();
$dataObject->getProperty('foo')->setValue($row['value']);

>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre]

Le 05/06/2021 à 12:06, Nikita Popov a écrit :

Yes, this is supported. What matters is the scope from which the
initialization occurs. If you rebind a closure to the scope of the class,
then you can perform any operations that would be legal inside that class,
including access to private properties and initialization of readonly
properties.

Regards,
Nikita


OK, I wasn't sure I thought I'd ask, this is nice, thank you !

I can't vote, but I love this RFC, thank you very much for this. I 
sincerely hope this will not get into flames.


--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Sat, Jun 5, 2021 at 11:47 AM Pierre  wrote:

> Le 04/06/2021 à 17:19, Nikita Popov a écrit :
>
> Hi internals,
>
> I'd like to open the discussion on readonly 
> properties:https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to thehttps://wiki.php.net/rfc/write_once_properties 
> RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section 
> (https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>
> Regards,
> Nikita
>
>
> Hello,
>
> If I understood it well you count assignments, one note thought after
> re-reading once again, you state:
>
> > This variant is not allowed, as the initializing assignment occurs from 
> > outside the class:
>
> Does this mean it'll prevent programmatic object hydration using the
> scope-stealing closure pattern ? Such as:
>
> 
> class SomeClass
> {
> public readonly int $foo;
> }
>
> $bar = 12;
>
>
> $object = (new 
> \ReflectionClass('SomeClass'))->newInstanceWithoutConstructor();
>
>
> (\Closure::bind(
> function (SomeClass $object) ($bar
> $object->foo = $bar;
> },
> null,
> SomeClass::class
> ))($object);
>
> ?>
>
> I know this is a weird stuff to do I wouldn't advise to others myself, but
> some hydration libraries such as ocramius/generated-hydrator do leverage
> this mechanism to hydrate objects, and I sometime do it myself in business
> code, sporadically, to hydrate objects from database without needing to
> define a constructor for those value objects.
>
Yes, this is supported. What matters is the scope from which the
initialization occurs. If you rebind a closure to the scope of the class,
then you can perform any operations that would be legal inside that class,
including access to private properties and initialization of readonly
properties.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Readonly properties

[Deleu]

On Sat, Jun 5, 2021, 11:47 Pierre  wrote:

> Le 04/06/2021 à 17:19, Nikita Popov a écrit :
> > Hi internals,
> >
> > I'd like to open the discussion on readonly properties:
> > https://wiki.php.net/rfc/readonly_properties_v2
> >
> > This proposal is similar to the
> > https://wiki.php.net/rfc/write_once_properties RFC that has been
> declined
> > previously. One significant difference is that the new RFC limits the
> scope
> > of initializing assignments. I think a key mistake of the previous RFC
> was
> > the confusing "write-once" framing, which is both technically correct and
> > quite irrelevant.
> >
> > Please see the rationale section (
> > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> > proposal relates to other RFCs and alternatives.
> >
> > Regards,
> > Nikita
> >
> Hello,
>
> If I understood it well you count assignments, one note thought after
> re-reading once again, you state:
>
> > This variant is not allowed, as the initializing assignment occurs from
> outside the class:
>
> Does this mean it'll prevent programmatic object hydration using the
> scope-stealing closure pattern ? Such as:
>
> 
> class SomeClass
> {
>  public readonly int $foo;
> }
>
> $bar = 12;
>
>
> $object = (new
> \ReflectionClass('SomeClass'))->newInstanceWithoutConstructor();
>
>
> (\Closure::bind(
>  function (SomeClass $object) ($bar
>  $object->foo = $bar;
>  },
>  null,
>  SomeClass::class
> ))($object);
>
> ?>
>
> I know this is a weird stuff to do I wouldn't advise to others myself,
> but some hydration libraries such as ocramius/generated-hydrator do
> leverage this mechanism to hydrate objects, and I sometime do it myself
> in business code, sporadically, to hydrate objects from database without
> needing to define a constructor for those value objects.
>
> If it does prevent such code, will there be some additional mechanism to
> create value objects with readonly properties without constructor ? Such
> as an JavaScript object-like object instanciation mechanism ?
>
> 
> class SomeClass
> {
>  public readonly int $foo;
> }
>
> $bar = 12;
>
> $object = {
>  foo: $bar,
> };
>
> ?>
>
> I know this goes far outside of this RFC's own scope, but maybe this is
> the occasion to open a discussion about this, this would play well with
> readonly properties and various serializers or hydrators libraries.
>
> Regards,
>
> --
>
> Pierre
>


Sounds like a revelant subject to be raised, indeed. But I honestly hope
that this awkward hack will not prevent us from getting read-only
attributes.

>

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre]

Le 04/06/2021 à 17:19, Nikita Popov a écrit :

Hi internals,

I'd like to open the discussion on readonly properties:
https://wiki.php.net/rfc/readonly_properties_v2

This proposal is similar to the
https://wiki.php.net/rfc/write_once_properties RFC that has been declined
previously. One significant difference is that the new RFC limits the scope
of initializing assignments. I think a key mistake of the previous RFC was
the confusing "write-once" framing, which is both technically correct and
quite irrelevant.

Please see the rationale section (
https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
proposal relates to other RFCs and alternatives.

Regards,
Nikita


Hello,

If I understood it well you count assignments, one note thought after 
re-reading once again, you state:


This variant is not allowed, as the initializing assignment occurs from outside the class: 


Does this mean it'll prevent programmatic object hydration using the 
scope-stealing closure pattern ? Such as:


newInstanceWithoutConstructor();


(\Closure::bind(
    function (SomeClass $object) ($bar
    $object->foo = $bar;
    },
    null,
    SomeClass::class
))($object);

?>

I know this is a weird stuff to do I wouldn't advise to others myself, 
but some hydration libraries such as ocramius/generated-hydrator do 
leverage this mechanism to hydrate objects, and I sometime do it myself 
in business code, sporadically, to hydrate objects from database without 
needing to define a constructor for those value objects.


If it does prevent such code, will there be some additional mechanism to 
create value objects with readonly properties without constructor ? Such 
as an JavaScript object-like object instanciation mechanism ?




I know this goes far outside of this RFC's own scope, but maybe this is 
the occasion to open a discussion about this, this would play well with 
readonly properties and various serializers or hydrators libraries.


Regards,

--

Pierre

Re: [PHP-DEV] [RFC] Readonly properties

[Nicolas Grekas]

Hi Nikita,

Le ven. 4 juin 2021 à 17:19, Nikita Popov  a écrit :

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>

Thanks for the proposal, that's quite appealing!

I voted "no" on the previous proposal because it didn't play well with
cloning. That's why I favoured asymmetric visibility.
I see that this new iteration has the same issue, so I'd like to know:

What about putting readonly properties in the uninitialized state when
cloning objects?

Cheers,
Nicolas

Re: [PHP-DEV] [RFC] Readonly properties

[Matthew Brown]

This is a great idea!

Might be worth mentioning that Psalm already supports a `@readonly`
docblock annotation (first suggested by Nuno Maduro), and it matches the
proposed behaviour (though Psalm doesn't currently prevent inheritance
issues):

Example: https://psalm.dev/r/7ed5872738

On Fri, 4 Jun 2021 at 11:19, Nikita Popov  wrote:

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre]

Le 04/06/2021 à 17:34, Pierre a écrit :

Le 04/06/2021 à 17:19, Nikita Popov a écrit :

Hi internals,

I'd like to open the discussion on readonly properties:
https://wiki.php.net/rfc/readonly_properties_v2

This proposal is similar to the
https://wiki.php.net/rfc/write_once_properties RFC that has been 
declined
previously. One significant difference is that the new RFC limits the 
scope
of initializing assignments. I think a key mistake of the previous 
RFC was
the confusing "write-once" framing, which is both technically correct 
and

quite irrelevant.

Please see the rationale section (
https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
proposal relates to other RFCs and alternatives.

Regards,
Nikita


Hello,

I like this RFC, but I have a question:

> Specifying an explicit default value on readonly properties is also 
not allowed:


Does that mean I wouldn't be allowed to write something such as:



Because the readonly+promoted+named combo is very powerful but if you 
can't assign defaults it makes it much less interesting.


Regards,

--

Pierre


Please ignore my mail, the answer is just below...

Sorry for the noise.

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre]

Le 04/06/2021 à 17:19, Nikita Popov a écrit :

Hi internals,

I'd like to open the discussion on readonly properties:
https://wiki.php.net/rfc/readonly_properties_v2

This proposal is similar to the
https://wiki.php.net/rfc/write_once_properties RFC that has been declined
previously. One significant difference is that the new RFC limits the scope
of initializing assignments. I think a key mistake of the previous RFC was
the confusing "write-once" framing, which is both technically correct and
quite irrelevant.

Please see the rationale section (
https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
proposal relates to other RFCs and alternatives.

Regards,
Nikita


Hello,

I like this RFC, but I have a question:

> Specifying an explicit default value on readonly properties is also 
not allowed:


Does that mean I wouldn't be allowed to write something such as:



Because the readonly+promoted+named combo is very powerful but if you 
can't assign defaults it makes it much less interesting.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

Hi internals,

I'd like to open the discussion on readonly properties:
https://wiki.php.net/rfc/readonly_properties_v2

This proposal is similar to the
https://wiki.php.net/rfc/write_once_properties RFC that has been declined
previously. One significant difference is that the new RFC limits the scope
of initializing assignments. I think a key mistake of the previous RFC was
the confusing "write-once" framing, which is both technically correct and
quite irrelevant.

Please see the rationale section (
https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
proposal relates to other RFCs and alternatives.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 24 Oct 2014, at 00:36, Andrea Faulds a...@ajf.me wrote:
 
 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

After further though, I am withdrawing this RFC. It’s confusing and a 
half-baked solution to the problem. Also, I’m not sure I like the idea of 
variable visibility accessors in any other form, either. So that’s that.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 29 Oct 2014, at 04:29, Jordi Boggiano j.boggi...@seld.be wrote:
 
 Yup that's definitely better than having the readonly flag in the {} block as 
 I had it.
 
 I'd however say that it should be possible to define a writable property with 
 only a getter and then the setter would implicitly be created. Since readonly 
 is the way to define writability why should I have to specify a setter (even 
 a default empty one) if none is needed?
 
 P.S: Don't want to open pandora's box, but we could also have writeonly for 
 completeness perhaps. I don't really see the use case at all though 
 (immutability sure, mutant bottomless pit objects not so much:).

I don’t think allowing write-only properties is a good idea if we need a new 
keyword for it.

To be honest, for such a use case, using a setter method is probably better 
than assigning as if it were a normal property. While people would probably 
tolerate and understand read-only (from their perspective outside the class) 
properties, I think write-only properties will just lead to poor API design and 
confusion.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Jordi Boggiano]

On 27/10/2014 20:27, Andrea Faulds wrote:

Tentative syntax. But this way, the visibility stays on the left. I think 
that’s good for readability. If you omit the second specifier, then the first 
one applies to getting and setting, as now. If you include it, the first one 
applies to getting, the second one to setting.

It’d also be compatible with properties, too:

 public/private $foobar {
 get { return $this-bar * $this-foo; }
 set($value) { $this-bar = $value / $this-foo; }
 }

It doesn’t prevent truly read-only properties, either:

 public $foobar {
 get { return $this-bar * $this-foo; }
 }

Does this sound like a good idea? A similar idea came up in the discussions 8 
years ago on readonly.


I like it, except for the fact that if you add a custom getter to a 
property suddenly it becomes readonly unless you remember to add ; set 
to the end of the block, right?


How about this instead for readonly:

  public $foobar {
  get { return $this-bar * $this-foo; }; readonly
  }

And if the flag isn't there, set is implicitly present.

That'd mean you also can keep public readonly $foobar; as a shorthand 
for readonly properties without custom getter.


Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Pierre Joye]

On Tue, Oct 28, 2014 at 2:17 PM, Jordi Boggiano j.boggi...@seld.be wrote:
 On 27/10/2014 20:27, Andrea Faulds wrote:

 Tentative syntax. But this way, the visibility stays on the left. I think
 that’s good for readability. If you omit the second specifier, then the
 first one applies to getting and setting, as now. If you include it, the
 first one applies to getting, the second one to setting.

 It’d also be compatible with properties, too:

  public/private $foobar {
  get { return $this-bar * $this-foo; }
  set($value) { $this-bar = $value / $this-foo; }
  }

 It doesn’t prevent truly read-only properties, either:

  public $foobar {
  get { return $this-bar * $this-foo; }
  }

 Does this sound like a good idea? A similar idea came up in the
 discussions 8 years ago on readonly.


 I like it, except for the fact that if you add a custom getter to a property
 suddenly it becomes readonly unless you remember to add ; set to the end
 of the block, right?

 How about this instead for readonly:

   public $foobar {
   get { return $this-bar * $this-foo; }; readonly
   }

 And if the flag isn't there, set is implicitly present.

 That'd mean you also can keep public readonly $foobar; as a shorthand for
 readonly properties without custom getter.

I like this idea.

Also confirmed what I was trying to say: While we can have many RFCs
covering the properties properties and behavior, having one covering
the needs in one go will allow us to be more consistent and developer
friendly.


-- 
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Chris Wright]

On 27 October 2014 20:27, Andrea Faulds a...@ajf.me wrote:


  On 26 Oct 2014, at 19:16, Rowan Collins rowan.coll...@gmail.com wrote:
 
  I just had a thought on both the naming and future-proofing concerns of
 this proposal: what about pre-emptively reserving the skeleton of the
 syntax needed for accessors, without actually implementing them?

 I’ve been thinking about this. While `public readonly $foo;` does work, it
 is confusing (only readonly to public) and limiting (no public/private
 option). Plus, while it could work with getters/setters, it’s hardly ideal.

 On the other hand, while having C#-style syntax here gives us a full
 feature set, I don’t like that it inverts the order of a declaration. To
 show you what I mean, here’s a normal property:

 public $foobar;

 Now, here’s a property with C#-style syntax:

 var $foobar { public get; private set; };

 See how the `public` moved to the right? I don’t like that, I want to
 avoid that if possible. I’m all for C#-style syntax with the get and set,
 but I don’t like that it moves the visibility specifier.

 Similarly, I don’t like this either:

 public $foobar { get; private set; }

 Now the visibility is on both sides! Yuck. That’s the worst of both worlds.

 What I’d like is probably something like this:

 public/private $foobar;

 Tentative syntax. But this way, the visibility stays on the left. I think
 that’s good for readability. If you omit the second specifier, then the
 first one applies to getting and setting, as now. If you include it, the
 first one applies to getting, the second one to setting.

 It’d also be compatible with properties, too:

 public/private $foobar {
 get { return $this-bar * $this-foo; }
 set($value) { $this-bar = $value / $this-foo; }
 }


Sorry, but I don't like this. This means that the visibility modifier is no
longer next to the thing that it applies to, IMO this is actually harmful
to the readability because the order in which the accessors were defined
then becomes significant so you have to either look at the ordering or have
the parser enforce a particular order, plus public/private looks
syntactically weird.

I would suggest something like this:

public $foobar {
get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}

...where only a single visibility modifier is permitted on the left, and
this is treated as the *default* visibility for the accessors, which are
free to declare another visibility if they want - so the following would be
equivalent:

public $foobar {
public get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}

Another bonus here is that the var keyword can still be permitted on the
left for those who prefer the C# syntax, as a synonym of public (i.e. the
current behaviour of var).

It doesn’t prevent truly read-only properties, either:

 public $foobar {
 get { return $this-bar * $this-foo; }
 }

 Does this sound like a good idea? A similar idea came up in the
 discussions 8 years ago on readonly.

 --
 Andrea Faulds
 http://ajf.me/





 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Rowan Collins]

Jordi Boggiano wrote on 28/10/2014 07:17:

How about this instead for readonly:

  public $foobar {
  get { return $this-bar * $this-foo; }; readonly
  }

And if the flag isn't there, set is implicitly present.

That'd mean you also can keep public readonly $foobar; as a 
shorthand for readonly properties without custom getter. 


I think it could be problematic to have too many variants of the syntax, 
as it leads to more inconsistencies that people have to understand, and 
more complex code needed in third-party parsers (IDEs, alternative 
implementations, etc).


Keeping the readonly attribute also keeps the ambiguity of what it 
actually means: immutable, protected, private? Sticking to the existing 
visibility modifiers makes it more explicit what's actually being set.


--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Rowan Collins]

Chris Wright wrote on 28/10/2014 09:46:

I would suggest something like this:

public $foobar {
get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}

...where only a single visibility modifier is permitted on the left, 
and this is treated as the *default* visibility for the accessors, 
which are free to declare another visibility if they want - so the 
following would be equivalent:


public $foobar {
public get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}


The reason I opted for using var rather than having modifiers on both 
sides was because I wasn't sure what should be done with expressions 
like this:


public $foo { private get; private set; }

Is that allowed, and actually creates a private property? Or does the 
compiler detect it and give some kind of error? It feels like a bug in 
the syntax that the same information is included in more than one place, 
meaning it can express contradictions.


--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 28 Oct 2014, at 07:17, Jordi Boggiano j.boggi...@seld.be wrote:
 
 I like it, except for the fact that if you add a custom getter to a property 
 suddenly it becomes readonly unless you remember to add ; set to the end of 
 the block, right?

Well, no. If you choose to specify getters and setters, and only specify a 
setter, of course it is read-only. It doesn’t make sense to have a getter and 
no setter and yet expect a property to be writeable.

 How about this instead for readonly:
 
  public $foobar {
  get { return $this-bar * $this-foo; }; readonly
  }
 
 And if the flag isn't there, set is implicitly present.

This is really confusing and I don’t think it’s a good idea. 
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 28 Oct 2014, at 09:46, Chris Wright c...@daverandom.com wrote:
 
 Sorry, but I don't like this. This means that the visibility modifier is no 
 longer next to the thing that it applies to,

I wouldn’t say that. The visibility modifier is an aspect of the property 
itself, not its implementation.  A property can be public-readable and 
private-writeable regardless of whether it’s a plain property or is a getter 
and a setter.

 IMO this is actually harmful to the readability because the order in which 
 the accessors were defined then becomes significant

It wouldn’t be significant. The public/private doesn’t apply to the getters and 
setters, it applies to reading and writing from the property, regardless of its 
implementation.

If we did’t enforce order, got the read/write syntax and getters and setters, 
hypothetically this would be possible:

public/private $foobar {
set($value) { … }
get { … }
}

However, hopefully coding style guides would discourage that.

 I would suggest something like this:
 
 public $foobar {
 get { return $this-bar * $this-foo; }
 private set($value) { $this-bar = $value / $this-foo }
 }
 
 ...where only a single visibility modifier is permitted on the left, and this 
 is treated as the *default* visibility for the accessors, which are free to 
 declare another visibility if they want

I don’t like this, it’s moving the visibility again and having it split between 
the start and end of the declaration.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Rowan Collins]

Andrea Faulds wrote on 28/10/2014 14:08:

On 28 Oct 2014, at 07:17, Jordi Boggianoj.boggi...@seld.be  wrote:

I like it, except for the fact that if you add a custom getter to a property suddenly it 
becomes readonly unless you remember to add ; set to the end of the block, right?

Well, no. If you choose to specify getters and setters, and only specify a 
setter, of course it is read-only. It doesn’t make sense to have a getter and 
no setter and yet expect a property to be writeable.



I think the problem is that the get and set annotations are serving 
multiple purposes - to change the visibility, to define custom 
accessor/mutator code, but also to declare whether certain actions are 
possible at all. Since the default is for the property to be readable 
and writable, the fact that adding { get; } makes it readonly isn't 
immediately intuitive, although it does makes sense once you think about it.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 28 Oct 2014, at 14:24, Rowan Collins rowan.coll...@gmail.com wrote:
 
 Andrea Faulds wrote on 28/10/2014 14:08:
 On 28 Oct 2014, at 07:17, Jordi Boggianoj.boggi...@seld.be  wrote:
 
 I like it, except for the fact that if you add a custom getter to a 
 property suddenly it becomes readonly unless you remember to add ; set 
 to the end of the block, right?
 Well, no. If you choose to specify getters and setters, and only specify a 
 setter, of course it is read-only. It doesn’t make sense to have a getter 
 and no setter and yet expect a property to be writeable.
 
 
 I think the problem is that the get and set annotations are serving multiple 
 purposes - to change the visibility, to define custom accessor/mutator code, 
 but also to declare whether certain actions are possible at all. Since the 
 default is for the property to be readable and writable, the fact that adding 
 { get; } makes it readonly isn't immediately intuitive, although it does 
 makes sense once you think about it.

Hmm. Perhaps we need this, then:

public $foobar; // public read, private write
public/private $foobar; // public read, private write
public readonly $foobar; // public read, not writeable at all

This then confined set/get entirely to implementation details. A read-only 
property would be denoted by readonly.

With the last one, you can only have get, for the first two, you must have both 
get and set.

Does that work? Seems pretty good to me.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Jordi Boggiano]

On 28/10/2014 15:08, Andrea Faulds wrote:



On 28 Oct 2014, at 14:24, Rowan Collins rowan.coll...@gmail.com wrote:

Andrea Faulds wrote on 28/10/2014 14:08:

On 28 Oct 2014, at 07:17, Jordi Boggianoj.boggi...@seld.be  wrote:

I like it, except for the fact that if you add a custom getter to a property suddenly it 
becomes readonly unless you remember to add ; set to the end of the block, 
right?

Well, no. If you choose to specify getters and setters, and only specify a 
setter, of course it is read-only. It doesn’t make sense to have a getter and 
no setter and yet expect a property to be writeable.



I think the problem is that the get and set annotations are serving multiple purposes - 
to change the visibility, to define custom accessor/mutator code, but also to declare 
whether certain actions are possible at all. Since the default is for the property to be 
readable and writable, the fact that adding { get; } makes it readonly isn't 
immediately intuitive, although it does makes sense once you think about it.


Hmm. Perhaps we need this, then:

public $foobar; // public read, private write
public/private $foobar; // public read, private write
public readonly $foobar; // public read, not writeable at all

This then confined set/get entirely to implementation details. A read-only 
property would be denoted by readonly.

With the last one, you can only have get, for the first two, you must have both 
get and set.

Does that work? Seems pretty good to me.


Yup that's definitely better than having the readonly flag in the {} 
block as I had it.


I'd however say that it should be possible to define a writable property 
with only a getter and then the setter would implicitly be created. 
Since readonly is the way to define writability why should I have to 
specify a setter (even a default empty one) if none is needed?


P.S: Don't want to open pandora's box, but we could also have writeonly 
for completeness perhaps. I don't really see the use case at all though 
(immutability sure, mutant bottomless pit objects not so much:).


Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Dmitry Stogov]

Hi Andrea,

I don't have strong opinion about this proposal.
It doesn't make any harm to the engine, and it really may speed-up code
especially written for read-only properties.
On the other hand you introduce new orthogonal to private/protected/public
visibility rule,
and I'm not sure if this complication is good for language.

Why did you disable read-only static methods? (I just didn't get it).

Thanks. Dmitry.

On Fri, Oct 24, 2014 at 3:36 AM, Andrea Faulds a...@ajf.me wrote:

 Good evening once again,

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

 It proposes, with a working implementation, a modifier for properties that
 makes them readable and writeable from different scopes.

 Since I am a big proponent of including specification patches in new RFCs,
 I have decided to put my money (or rather, time) where my mouth is and I
 have actually written a specification patch before writing an RFC. I would
 love to see this become the new standard for RFCs affecting the language.

 If you are curious at all about the behaviour, I suggest perusing the
 fairly comprehensive set of twelve tests included in the main patch to
 php-src.

 Thanks!
 --
 Andrea Faulds
 http://ajf.me/





 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 27 Oct 2014, at 18:31, Dmitry Stogov dmi...@zend.com wrote:
 
 Hi Andrea,
 
 I don't have strong opinion about this proposal.
 It doesn't make any harm to the engine, and it really may speed-up code 
 especially written for read-only properties.
 On the other hand you introduce new orthogonal to private/protected/public 
 visibility rule,
 and I'm not sure if this complication is good for language.
 
 Why did you disable read-only static methods? (I just didn't get it).

You couldn't really have a read-only method, there's no get/set equivalent for 
methods. The reason they're explicitly disallowed in the code is because, to 
avoid shift/reduce conflicts, I have to add it as a member modifier but then 
check the AST to see if it was used.

The reason for disallowing static methods is we currently don't use separate 
code paths for get/set of static methods, we just call one function to obtain a 
pointer. Of course I could make that function be told whether it's for writing, 
I just hadn't done it yet.

--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Dmitry Stogov]

On Mon, Oct 27, 2014 at 10:25 PM, Andrea Faulds a...@ajf.me wrote:


  On 27 Oct 2014, at 18:31, Dmitry Stogov dmi...@zend.com wrote:
 
  Hi Andrea,
 
  I don't have strong opinion about this proposal.
  It doesn't make any harm to the engine, and it really may speed-up code
 especially written for read-only properties.
  On the other hand you introduce new orthogonal to
 private/protected/public visibility rule,
  and I'm not sure if this complication is good for language.
 
  Why did you disable read-only static methods? (I just didn't get it).

 You couldn't really have a read-only method, there's no get/set equivalent
 for methods. The reason they're explicitly disallowed in the code is
 because, to avoid shift/reduce conflicts, I have to add it as a member
 modifier but then check the AST to see if it was used.

 The reason for disallowing static methods is we currently don't use
 separate code paths for get/set of static methods, we just call one
 function to obtain a pointer. Of course I could make that function be told
 whether it's for writing, I just hadn't done it yet.


Oh. I meant static properties, of course. (zend_compile.c line 4219)

Thanks. Dmitry.



 --
 Andrea Faulds
 http://ajf.me/

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 27 Oct 2014, at 19:47, Dmitry Stogov dmi...@zend.com wrote:
 
 Oh. I meant static properties, of course. (zend_compile.c line 4219)

So did I in the second paragraph. Static property get and set currently goes 
through the same function… but really the reason they’re disallowed is me not 
getting round to implementing them yet.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 26 Oct 2014, at 19:16, Rowan Collins rowan.coll...@gmail.com wrote:
 
 I just had a thought on both the naming and future-proofing concerns of this 
 proposal: what about pre-emptively reserving the skeleton of the syntax 
 needed for accessors, without actually implementing them?

I’ve been thinking about this. While `public readonly $foo;` does work, it is 
confusing (only readonly to public) and limiting (no public/private option). 
Plus, while it could work with getters/setters, it’s hardly ideal.

On the other hand, while having C#-style syntax here gives us a full feature 
set, I don’t like that it inverts the order of a declaration. To show you what 
I mean, here’s a normal property:

public $foobar;

Now, here’s a property with C#-style syntax:

var $foobar { public get; private set; };

See how the `public` moved to the right? I don’t like that, I want to avoid 
that if possible. I’m all for C#-style syntax with the get and set, but I don’t 
like that it moves the visibility specifier.

Similarly, I don’t like this either:

public $foobar { get; private set; }

Now the visibility is on both sides! Yuck. That’s the worst of both worlds.

What I’d like is probably something like this:

public/private $foobar;

Tentative syntax. But this way, the visibility stays on the left. I think 
that’s good for readability. If you omit the second specifier, then the first 
one applies to getting and setting, as now. If you include it, the first one 
applies to getting, the second one to setting.

It’d also be compatible with properties, too:

public/private $foobar {
get { return $this-bar * $this-foo; }
set($value) { $this-bar = $value / $this-foo; }
}

It doesn’t prevent truly read-only properties, either:

public $foobar {
get { return $this-bar * $this-foo; }
}

Does this sound like a good idea? A similar idea came up in the discussions 8 
years ago on readonly.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Dmitry Stogov]

if there are no conceptual and implantation problems with static readonly
properties, it's better to implement them in the same patch.

On Mon, Oct 27, 2014 at 11:15 PM, Andrea Faulds a...@ajf.me wrote:


  On 27 Oct 2014, at 19:47, Dmitry Stogov dmi...@zend.com wrote:
 
  Oh. I meant static properties, of course. (zend_compile.c line 4219)

 So did I in the second paragraph. Static property get and set currently
 goes through the same function… but really the reason they’re disallowed is
 me not getting round to implementing them yet.

 --
 Andrea Faulds
 http://ajf.me/

Re: [PHP-DEV] [RFC] Readonly Properties

[Jordi Boggiano]

On 24/10/2014 12:54, Andrea Faulds wrote:



On 24 Oct 2014, at 10:29, Jordi Boggiano j.boggi...@seld.be wrote:

Thanks for the work (again). It's an interesting small idea but I'd much prefer 
revisiting the original getter/setter RFC [1] which had a majority but just 
fell short of the 66% mark.

This RFC only implements parts of the getter/setter functionality (readonly 
properties) but it does not address the fact that sometimes you want to add 
logic to a setter or a getter and if you don't have language level 
getters/setters you end up having to change the interface of the object from a 
public property to a getFoo/setFoo pair.

This leads to everyone having getFoo/setFoo by default just to avoid interface 
changes or mixed interfaces of public properties and setFoo.




On 24 Oct 2014, at 10:34, Pierre Joye pierre@gmail.com wrote:

As much i really like the idea to have better properties management in
PHP I see this RFC as an attempt to solve only part of the problem
while dropping most of the other ideas implemented in the past RFCs.
My take on that is that some will vote no, or won't like the idea of
adding anything in this area. Making compromises and implement partial
solutions will only delay the implementation of the complete solution.

Many of us agree that __get/__set is a pain to deal with.The need of
readonly, writeonly or properties with some logic to define or get a
value is a lond due need. Many other languages support that out of the
box since long already. Past RFCs, like the c# one, proposed that. I
would rather focus on trying to find an acceptable syntax and
implementation instead of doing baby steps like that. Baby steps work
very well for scalar type hinting, solving one issue after another,
etc. But for properties we are at the risk of hainvg a serie of
separate RFCs solving the properties management problems in different
ways bringing even more troubles and inconsistencies.


I think I might be misunderstood, here. While getters and setters can
do this, and I’m very much in favour of also reviving a simplified
version of the getter/setter RFC (previous one was way too complex),
I don’t see this as partly implementing them/baby steps/etc. I fact,
I think readonly properties could work together with
getters/setters.


Fair enough, thanks for the clarification. It also sounds good to have 
very simple getter/setters when needed and simple properties + 
eventually readonly otherwise. issetters/unsetters aren't extremely needed.


Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Rowan Collins]

On 24/10/2014 00:36, Andrea Faulds wrote:

Good evening once again,

Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

It proposes, with a working implementation, a modifier for properties that 
makes them readable and writeable from different scopes.

Since I am a big proponent of including specification patches in new RFCs, I 
have decided to put my money (or rather, time) where my mouth is and I have 
actually written a specification patch before writing an RFC. I would love to 
see this become the new standard for RFCs affecting the language.

If you are curious at all about the behaviour, I suggest perusing the fairly 
comprehensive set of twelve tests included in the main patch to php-src.

Thanks!


I just had a thought on both the naming and future-proofing concerns of 
this proposal: what about pre-emptively reserving the skeleton of the 
syntax needed for accessors, without actually implementing them?


For instance, one of the (confusingly many) syntaxes allowed by 
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 would have been this:


private $foo { public get; protected set; }

In that instance, this was seen as short-hand for the default proxy 
method, but the effect is to modify the visibility of the property 
without any extra behaviour.


If we remove the requirement to specify both get and set if the guard 
clause is added, we get a simple syntax that covers the two cases the 
RFC's readonly keyword does, plus one more:


// Current RFC
public readonly $foo; // read public, write protected
protected readonly $foo; // read protected, write private

// With only set keyword
public $foo { protected set; }
protected $foo { private set; }
public $foo { private set; }  // read public, write private

// With only get keyword
protected $foo { public get; }
private $foo { protected get; }
private $foo { public get; }

// With both keywords, since var has been undeprecated
var $foo { public get; protected set; }
var $foo { protected get; private set; }
var $foo { public get; private set; }

This syntax does imply other combinations like private get; public 
set; (effectively write-only from certain scopes), which may 
complicate matters somewhat. To keep things simple, we could simply 
enforce a rule at compile time that read visibility must not be more 
restrictive than write visibility.


This gets rid of the ambiguity of the readonly keyword, and makes the 
behaviour of read protected, write private much more obvious. It also 
opens the door to syntax for accessors without placing much restriction 
on how they could work...


// Forwards compatible to all these and more...
var $foo { public get { return $this-bar * 10; } private set; }
var $foo { public get() { return $this-bar * 10; } private set; }
var $foo { public get = $this-bar * 10; private set; }
var $foo { public get: existingMethod; private set; }

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 24 Oct 2014, at 06:09, Xinchen Hui larue...@php.net wrote:

 so you prefer to expose the name of the property anywhere?
 
 let's say you expose a readonly int value name iSize..
 
 but later, the value also need to be a double,
 
 then you also prefer add another dval? (since you can not simple
 change ival name, since it was exposed)

Is that not already a problem with functions? You can't change their names. If 
you do change its name, you can add a __get.

 I knew this of course, but this is actually not related to this
 specific readonly RFC
 
 but if you are strict to this., then I'd like to say, this will
 slowdown all FETCH_OBJ_R a bit, since this will need introduce a
 condition to check whether a property is readonly..  only faster a
 narrow case...

Right, it will theoretically make public and protected property lookups 
ever-so-slightly slower. I'll need to benchmark it as I doubt it's a big deal 
in practice.

Though this could be worked around by making the write check be a different 
function. Or by inlining.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Rowan Collins]

On 24 October 2014 00:36:35 GMT+01:00, Andrea Faulds a...@ajf.me wrote:
Good evening once again,

Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

It proposes, with a working implementation, a modifier for properties
that makes them readable and writeable from different scopes.

Since I am a big proponent of including specification patches in new
RFCs, I have decided to put my money (or rather, time) where my mouth
is and I have actually written a specification patch before writing an
RFC. I would love to see this become the new standard for RFCs
affecting the language.

If you are curious at all about the behaviour, I suggest perusing the
fairly comprehensive set of twelve tests included in the main patch to
php-src.

Thanks!
--
Andrea Faulds
http://ajf.me/

If nothing else, I like that this brings userland objects another step closer 
to those defined in extensions, which frequently use readonly properties.

I note that UString advertises a -length rather than a -getLength, and I 
haven't seen anyone in that thread object to that design decision, so I don't 
really buy the you should never need this argument.

The additional keyword and potential performance impact are more concerning, 
and will need to be weighed carefully against the benefits.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrey Andreev]

Hi,

On Fri, Oct 24, 2014 at 2:36 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening once again,

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

 It proposes, with a working implementation, a modifier for properties that 
 makes them readable and writeable from different scopes.

 Since I am a big proponent of including specification patches in new RFCs, I 
 have decided to put my money (or rather, time) where my mouth is and I have 
 actually written a specification patch before writing an RFC. I would love to 
 see this become the new standard for RFCs affecting the language.

 If you are curious at all about the behaviour, I suggest perusing the fairly 
 comprehensive set of twelve tests included in the main patch to php-src.

+1

I've always wanted this, it has never made sense to me to write
numerous lines of code just to make an already declared property
*readable* from outside a class. __get() has helped to some extent,
but it has its disadvantages.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Patrick Schaaf]

Am 24.10.2014 01:36 schrieb Andrea Faulds a...@ajf.me:

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

+1 for the general feature, I'd love to have that available.

I have an idea regarding the additional keyword, with a small implication
(improvement) to the functionality provided, but at the cost of being
slightly quirky :) The idea is:

public $foo as private;
public $bar as protected;
protected $baz as private;

where the as X gives the writability scope. This introduces no new
keywords, and is currently not valid syntax, as far as I can see.

best regards
  Patrick

Re: [PHP-DEV] [RFC] Readonly Properties

[Jordi Boggiano]

On 24/10/2014 00:36, Andrea Faulds wrote:

Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

It proposes, with a working implementation, a modifier for properties
that makes them readable and writeable from different scopes.

Since I am a big proponent of including specification patches in new
RFCs, I have decided to put my money (or rather, time) where my mouth
is and I have actually written a specification patch before writing
an RFC. I would love to see this become the new standard for RFCs
affecting the language.


Thanks for the work (again). It's an interesting small idea but I'd much 
prefer revisiting the original getter/setter RFC [1] which had a 
majority but just fell short of the 66% mark.


This RFC only implements parts of the getter/setter functionality 
(readonly properties) but it does not address the fact that sometimes 
you want to add logic to a setter or a getter and if you don't have 
language level getters/setters you end up having to change the interface 
of the object from a public property to a getFoo/setFoo pair.


This leads to everyone having getFoo/setFoo by default just to avoid 
interface changes or mixed interfaces of public properties and setFoo.


[1] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Pierre Joye]

hi Andrea,

On Fri, Oct 24, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening once again,

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

 It proposes, with a working implementation, a modifier for properties that 
 makes them readable and writeable from different scopes.

 Since I am a big proponent of including specification patches in new RFCs, I 
 have decided to put my money (or rather, time) where my mouth is and I have 
 actually written a specification patch before writing an RFC. I would love to 
 see this become the new standard for RFCs affecting the language.

 If you are curious at all about the behaviour, I suggest perusing the fairly 
 comprehensive set of twelve tests included in the main patch to php-src.

As much i really like the idea to have better properties management in
PHP I see this RFC as an attempt to solve only part of the problem
while dropping most of the other ideas implemented in the past RFCs.
My take on that is that some will vote no, or won't like the idea of
adding anything in this area. Making compromises and implement partial
solutions will only delay the implementation of the complete solution.

Many of us agree that __get/__set is a pain to deal with.The need of
readonly, writeonly or properties with some logic to define or get a
value is a lond due need. Many other languages support that out of the
box since long already. Past RFCs, like the c# one, proposed that. I
would rather focus on trying to find an acceptable syntax and
implementation instead of doing baby steps like that. Baby steps work
very well for scalar type hinting, solving one issue after another,
etc. But for properties we are at the risk of hainvg a serie of
separate RFCs solving the properties management problems in different
ways bringing even more troubles and inconsistencies.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Nikita Popov]

On Fri, Oct 24, 2014 at 1:36 AM, Andrea Faulds a...@ajf.me wrote:

 Good evening once again,

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

 It proposes, with a working implementation, a modifier for properties that
 makes them readable and writeable from different scopes.

 Since I am a big proponent of including specification patches in new RFCs,
 I have decided to put my money (or rather, time) where my mouth is and I
 have actually written a specification patch before writing an RFC. I would
 love to see this become the new standard for RFCs affecting the language.

 If you are curious at all about the behaviour, I suggest perusing the
 fairly comprehensive set of twelve tests included in the main patch to
 php-src.

 Thanks!


While I think the functionality behind this proposal is nice in principle,
I have two objections with the RFC:

1. It uses the readonly modifier, to refer to a property that is publicly
readable, but protectedly writable (or protectedly readable and privately
writable). This isn't entirely obvious from the term readonly and also
does not match the behavior of other languages employing a readonly
modifier, like C#. An additional complication may be encountered in the
case where the readonly property stores an object, in which case I presume
it will be possible to modify the stored object ($obj-readonlyProp-prop =
42), which is likely not expected readonly behavior.

2. If the aim of this RFC is to replace the getFoo() pattern with the use
of readonly public $foo properties, a primary difference will be that a
getFoo() method can be declared in an interface, whereas a readonly public
$foo property cannot be. Thus code making use of interfaces will not be
able to employ this feature. And I don't think that allowing properties in
interfaces is reasonable at this point, because the implementations will be
limited to simple-storage properties - only with more comprehensive
property accessor support would implementations be allowed to use more
complex backing code.

For these reasons I do not think this RFC is suitable for inclusion in PHP
in its current state. As others in this thread have already pointed out, it
may be advisable to reconsider readonly properties in the broader context
of property accessors.

Nikita

Re: [PHP-DEV] [RFC] Readonly Properties

[Alain Williams]

On Fri, Oct 24, 2014 at 10:41:38AM +0200, Patrick Schaaf wrote:
 Am 24.10.2014 01:36 schrieb Andrea Faulds a...@ajf.me:
 
  Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
 
 +1 for the general feature, I'd love to have that available.
 
 I have an idea regarding the additional keyword, with a small implication
 (improvement) to the functionality provided, but at the cost of being
 slightly quirky :) The idea is:
 
 public $foo as private;
 public $bar as protected;
 protected $baz as private;
 
 where the as X gives the writability scope. This introduces no new
 keywords, and is currently not valid syntax, as far as I can see.

More as musing than anything else - might provide some insight via an analogy.

Properties and methods have a scope that is: private, protected or public.
This reminds me of the Unix: owner, group  other file permissions.

Unix allows: read, write  execute.

This RFC is trying to control how a property could be used with a readonly 
restriction.
Are there times when one would want to be able to set a property value - but not
read it ?

Thinking about execute - would there be any mileage in an execute permission -
could be useful for a property that had been assigned an anonymous function.


Finally we could bring it all together and sidestep the scoping keywords using
'var' instead. Thus:

var $callback as 0751;

Would define a property that contains an anonymous function that could be called
by anyone, inspected by the class  related class, but only set by the class 
itself!

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Florian Margaine]

Hi,

On Fri, Oct 24, 2014 at 12:21 PM, Alain Williams a...@phcomp.co.uk wrote:

 On Fri, Oct 24, 2014 at 10:41:38AM +0200, Patrick Schaaf wrote:
  Am 24.10.2014 01:36 schrieb Andrea Faulds a...@ajf.me:
  
   Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
 
  +1 for the general feature, I'd love to have that available.
 
  I have an idea regarding the additional keyword, with a small implication
  (improvement) to the functionality provided, but at the cost of being
  slightly quirky :) The idea is:
 
  public $foo as private;
  public $bar as protected;
  protected $baz as private;
 
  where the as X gives the writability scope. This introduces no new
  keywords, and is currently not valid syntax, as far as I can see.

 More as musing than anything else - might provide some insight via an
 analogy.

 Properties and methods have a scope that is: private, protected or public.
 This reminds me of the Unix: owner, group  other file permissions.

 Unix allows: read, write  execute.

 This RFC is trying to control how a property could be used with a readonly
 restriction.
 Are there times when one would want to be able to set a property value -
 but not
 read it ?

 Thinking about execute - would there be any mileage in an execute
 permission -
 could be useful for a property that had been assigned an anonymous
 function.


 Finally we could bring it all together and sidestep the scoping keywords
 using
 'var' instead. Thus:

 var $callback as 0751;

 Would define a property that contains an anonymous function that could be
 called
 by anyone, inspected by the class  related class, but only set by the
 class itself!


To follow up on this, and to give more readable code, we could also use
this:

var $callback as rwxrw---x;



 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information:
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


Regards,

-- 
Florian Margaine

Re: [PHP-DEV] [RFC] Readonly Properties

[Alain Williams]

On Fri, Oct 24, 2014 at 12:29:57PM +0200, Florian Margaine wrote:

  Finally we could bring it all together and sidestep the scoping keywords
  using
  'var' instead. Thus:
 
  var $callback as 0751;
 
  Would define a property that contains an anonymous function that could be
  called
  by anyone, inspected by the class  related class, but only set by the
  class itself!
 
 
 To follow up on this, and to give more readable code, we could also use
 this:
 
 var $callback as rwxrw---x;

+1, although that would have been:

var $callback as rwxr-x--x;

Again musing further:

var $callback as rwsr-x--x;

A callback that when executed/called would have 'private' access permissions on 
properties!

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrey Andreev]

Hi,

On Fri, Oct 24, 2014 at 12:34 PM, Pierre Joye pierre@gmail.com wrote:
 hi Andrea,

 On Fri, Oct 24, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening once again,

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

 It proposes, with a working implementation, a modifier for properties that 
 makes them readable and writeable from different scopes.

 Since I am a big proponent of including specification patches in new RFCs, I 
 have decided to put my money (or rather, time) where my mouth is and I have 
 actually written a specification patch before writing an RFC. I would love 
 to see this become the new standard for RFCs affecting the language.

 If you are curious at all about the behaviour, I suggest perusing the fairly 
 comprehensive set of twelve tests included in the main patch to php-src.

 As much i really like the idea to have better properties management in
 PHP I see this RFC as an attempt to solve only part of the problem
 while dropping most of the other ideas implemented in the past RFCs.
 My take on that is that some will vote no, or won't like the idea of
 adding anything in this area. Making compromises and implement partial
 solutions will only delay the implementation of the complete solution.

 Many of us agree that __get/__set is a pain to deal with.The need of
 readonly, writeonly or properties with some logic to define or get a
 value is a lond due need. Many other languages support that out of the
 box since long already. Past RFCs, like the c# one, proposed that. I
 would rather focus on trying to find an acceptable syntax and
 implementation instead of doing baby steps like that. Baby steps work
 very well for scalar type hinting, solving one issue after another,
 etc. But for properties we are at the risk of hainvg a serie of
 separate RFCs solving the properties management problems in different
 ways bringing even more troubles and inconsistencies.

Pierre, I rarely disagree with you, but this is one such case.

It is true that we can look at this as a partial solution to a bigger
problem, or as you said - a baby step. However, I see this as the
perfect solution for a very narrow, yet also a very common problem,
and I don't see it blocking a more abstract solution in the future.

From a userland POV, it is simple, very effective and there's
practically no way to achieve the same goal with less amount of code.

In short - it's no panacea to all the limitations that we currently
have on property management, but it is still *extremely* useful for
implementing classes that only need to have getters.

On another note, I share Nikita's concern about using the readonly
keyword and I'd love that to be improved, but the best alternative I
could think of is readable and IMO it doesn't have a clearer
meaning.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 24 Oct 2014, at 10:29, Jordi Boggiano j.boggi...@seld.be wrote:
 
 Thanks for the work (again). It's an interesting small idea but I'd much 
 prefer revisiting the original getter/setter RFC [1] which had a majority but 
 just fell short of the 66% mark.
 
 This RFC only implements parts of the getter/setter functionality (readonly 
 properties) but it does not address the fact that sometimes you want to add 
 logic to a setter or a getter and if you don't have language level 
 getters/setters you end up having to change the interface of the object from 
 a public property to a getFoo/setFoo pair.
 
 This leads to everyone having getFoo/setFoo by default just to avoid 
 interface changes or mixed interfaces of public properties and setFoo.

 
 On 24 Oct 2014, at 10:34, Pierre Joye pierre@gmail.com wrote:
 
 As much i really like the idea to have better properties management in
 PHP I see this RFC as an attempt to solve only part of the problem
 while dropping most of the other ideas implemented in the past RFCs.
 My take on that is that some will vote no, or won't like the idea of
 adding anything in this area. Making compromises and implement partial
 solutions will only delay the implementation of the complete solution.
 
 Many of us agree that __get/__set is a pain to deal with.The need of
 readonly, writeonly or properties with some logic to define or get a
 value is a lond due need. Many other languages support that out of the
 box since long already. Past RFCs, like the c# one, proposed that. I
 would rather focus on trying to find an acceptable syntax and
 implementation instead of doing baby steps like that. Baby steps work
 very well for scalar type hinting, solving one issue after another,
 etc. But for properties we are at the risk of hainvg a serie of
 separate RFCs solving the properties management problems in different
 ways bringing even more troubles and inconsistencies.

I think I might be misunderstood, here. While getters and setters can do this, 
and I’m very much in favour of also reviving a simplified version of the 
getter/setter RFC (previous one was way too complex), I don’t see this as 
partly implementing them/baby steps/etc. I fact, I think readonly properties 
could work together with getters/setters.

I don't like using property getters and setters to control whether a property 
can be written to or read from. I think they're the wrong solution for that - 
why have a virtual property with boilerplate restricted visibility accessors 
and mutators that get/set a hidden private property, with their associated 
performance penalties, when you can just make a real property that can't be 
read by outsiders?

I think getters and setters are useful and I probably will try to revive them 
too sometime soon, but I think they’re actually the wrong tool for this 
specific job.


--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 24 Oct 2014, at 11:20, Nikita Popov nikita@gmail.com wrote:
 
 While I think the functionality behind this proposal is nice in principle, I 
 have two objections with the RFC:
 
 1. It uses the readonly modifier, to refer to a property that is publicly 
 readable, but protectedly writable (or protectedly readable and privately 
 writable). This isn't entirely obvious from the term readonly and also does 
 not match the behavior of other languages employing a readonly modifier, 
 like C#. An additional complication may be encountered in the case where the 
 readonly property stores an object, in which case I presume it will be 
 possible to modify the stored object ($obj-readonlyProp-prop = 42), which 
 is likely not expected readonly behavior.

It’s not the best name, I agree, but there isn’t a better name I could come up 
with in discussions. I don’t think the object thing is an issue, it’s not like 
there’s much we can do about that.
 
 2. If the aim of this RFC is to replace the getFoo() pattern with the use of 
 readonly public $foo properties, a primary difference will be that a 
 getFoo() method can be declared in an interface, whereas a readonly public 
 $foo property cannot be. Thus code making use of interfaces will not be able 
 to employ this feature. And I don't think that allowing properties in 
 interfaces is reasonable at this point, because the implementations will be 
 limited to simple-storage properties - only with more comprehensive property 
 accessor support would implementations be allowed to use more complex backing 
 code.

Right, interfaces currently can’t declare properties and I’m not going to 
change that in this RFC. If I revisit getters and setters, that would be 
changed. Still, I think there is usefulness to this without interfaces… it’s 
just more limited, sadly.

It would work quite well with getters and setters and interfaces, if later 
added. Within interfaces, readonly could be used to avoid compelling 
implementing classes to support writing:

interface Point {
 public readonly $x, $y;
}

But without preventing implementing classes from supporting it.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 24 Oct 2014, at 12:12, Andrey Andreev n...@devilix.net wrote:
 
 Pierre, I rarely disagree with you, but this is one such case.
 
 It is true that we can look at this as a partial solution to a bigger
 problem, or as you said - a baby step. However, I see this as the
 perfect solution for a very narrow, yet also a very common problem,
 and I don't see it blocking a more abstract solution in the future.

That’s basically my thoughts on this RFC. I think it’s still quite useful even 
if it’s not as useful as it could be without certain other additions.

 
 From a userland POV, it is simple, very effective and there's
 practically no way to achieve the same goal with less amount of code.
 
 In short - it's no panacea to all the limitations that we currently
 have on property management, but it is still *extremely* useful for
 implementing classes that only need to have getters.

It’s also faster!

 On another note, I share Nikita's concern about using the readonly
 keyword and I'd love that to be improved, but the best alternative I
 could think of is readable and IMO it doesn't have a clearer
 meaning.

Yeah, that’s the problem. It is somewhat unclear, but any other keyword choice 
is even more confusing. I discussed this quite a bit in StackOverflow’s PHP 
chatroom (http://chat.stackoverflow.com/rooms/11/php) and couldn’t come up with 
anything better.

Also, as I note in the RFC, we already use readonly in the docs for some 
classes, and for C#-style only-set-once read-only properties, we could use 
final or immutable.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

 On 24 Oct 2014, at 12:59, Andrea Faulds a...@ajf.me wrote:
 
 
 2. If the aim of this RFC is to replace the getFoo() pattern with the use of 
 readonly public $foo properties, a primary difference will be that a 
 getFoo() method can be declared in an interface, whereas a readonly public 
 $foo property cannot be. Thus code making use of interfaces will not be 
 able to employ this feature. And I don't think that allowing properties in 
 interfaces is reasonable at this point, because the implementations will be 
 limited to simple-storage properties - only with more comprehensive property 
 accessor support would implementations be allowed to use more complex 
 backing code.
 
 Right, interfaces currently can’t declare properties and I’m not going to 
 change that in this RFC. If I revisit getters and setters, that would be 
 changed. Still, I think there is usefulness to this without interfaces… it’s 
 just more limited, sadly.
 
 It would work quite well with getters and setters and interfaces, if later 
 added. Within interfaces, readonly could be used to avoid compelling 
 implementing classes to support writing:
 
 interface Point {
 public readonly $x, $y;
 }
 
 But without preventing implementing classes from supporting it.

I added a little Future Scope section on this: 
https://wiki.php.net/rfc/readonly_properties#puture_scope

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Stas Malyshev]

Hi!

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
 
 It proposes, with a working implementation, a modifier for properties that 
 makes them readable and writeable from different scopes.

For me, this seems both too big and too small. Too small, because if you
really it assigns a keyword to special use case of a generic feature,
and thus I think does not lead us on the right path - we could not
assign keywords to every behavior of properties, so either we forever
reject the idea of having any generic solution there, or we'd eventually
have two solutions, working in two different ways.

Too big because this particular case is already very easy to implement
by just making the property protected and having a public getter. It
doesn't add any capability that we already don't have, and having a
keyword just to save typing () seems unnecessary to me (performance is
really irrelevant here, if your performance is bound by speed of
accessors, you should be writing that code in C).

Also, the name readonly appears misleading as it's not really read
only - it's only read only for some classes, but writeable for others.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Kalle Sommer Nielsen]

2014-10-24 7:09 GMT+02:00 Xinchen Hui larue...@php.net:
 so you prefer to expose the name of the property anywhere?

 let's say you expose a readonly int value name iSize..

 but later, the value also need to be a double,

 then you also prefer add another dval? (since you can not simple
 change ival name, since it was exposed)

That is purely a naming decision, not something that should cause the
actual design of a language to not be available and even then, what
you are saying seems like a very edge case to me and I have a hard
time trying to understand if as I understand it, is your argument
against this feature.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Readonly Properties

[Andrea Faulds]

Good evening once again,

Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

It proposes, with a working implementation, a modifier for properties that 
makes them readable and writeable from different scopes.

Since I am a big proponent of including specification patches in new RFCs, I 
have decided to put my money (or rather, time) where my mouth is and I have 
actually written a specification patch before writing an RFC. I would love to 
see this become the new standard for RFCs affecting the language.

If you are curious at all about the behaviour, I suggest perusing the fairly 
comprehensive set of twelve tests included in the main patch to php-src.

Thanks!
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Xinchen Hui]

Hey:


On Fri, Oct 24, 2014 at 7:36 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening once again,

 Here’s another RFC: https://wiki.php.net/rfc/readonly_properties

 It proposes, with a working implementation, a modifier for properties that 
 makes them readable and writeable from different scopes.

 Since I am a big proponent of including specification patches in new RFCs, I 
 have decided to put my money (or rather, time) where my mouth is and I have 
 actually written a specification patch before writing an RFC. I would love to 
 see this become the new standard for RFCs affecting the language.

 If you are curious at all about the behaviour, I suggest perusing the fairly 
 comprehensive set of twelve tests included in the main patch to php-src.

 Thanks!
Hey:

   -1 on this.

   Actually,   your example for explaining usage..

I don't see why it is must, add a getSize() will also meet the
needs, and more beatiful, as you can change $size to another name if
you like later.

  thanks


 --
 Andrea Faulds
 http://ajf.me/





 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Kalle Sommer Nielsen]

Hi

2014-10-24 5:02 GMT+02:00 Xinchen Hui larue...@php.net:
 Hey:

-1 on this.

Actually,   your example for explaining usage..

 I don't see why it is must, add a getSize() will also meet the
 needs, and more beatiful, as you can change $size to another name if
 you like later.

I disagree on your disagreement, while it is not a must, it does not
make much sense that we are gonna call what essential is a function to
return a value that is not changed in anyway during that call. It does
not really perform a function, other than returning a value in 99% of
all cases, and therefore it makes perfect sense to allow readonly
properties in my mind.

It does not really make the code beautiful to prefix it with 'get' and
suffix it with '()' when you want such a value, it makes it
consistent, yes, but else it is just bloat to my eyes.

Internally it should also be a slightly be faster to not having to
call a method everytime as well, a program that does, lets say 50-100
calls to 'getX()' that can skip INIT_METHOD_CALL + DO_FCALL_BY_NAME
and instead just a FETCH_OBJ_R which is what should be after the
fcall, micro optimization I know (been a while since I went into these
parts so I might be a bit off though).

I'm a huge +1 on this, good job Andrea!


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Readonly Properties

[Xinchen Hui]

On Fri, Oct 24, 2014 at 12:11 PM, Kalle Sommer Nielsen ka...@php.net wrote:
 Hi

 2014-10-24 5:02 GMT+02:00 Xinchen Hui larue...@php.net:
 Hey:

-1 on this.

Actually,   your example for explaining usage..

 I don't see why it is must, add a getSize() will also meet the
 needs, and more beatiful, as you can change $size to another name if
 you like later.

 I disagree on your disagreement, while it is not a must, it does not
 make much sense that we are gonna call what essential is a function to
 return a value that is not changed in anyway during that call. It does
 not really perform a function, other than returning a value in 99% of
 all cases, and therefore it makes perfect sense to allow readonly
 properties in my mind.

 It does not really make the code beautiful to prefix it with 'get' and
 suffix it with '()' when you want such a value, it makes it
 consistent, yes, but else it is just bloat to my eyes.
so you prefer to expose the name of the property anywhere?

let's say you expose a readonly int value name iSize..

but later, the value also need to be a double,

then you also prefer add another dval? (since you can not simple
change ival name, since it was exposed)


 Internally it should also be a slightly be faster to not having to
 call a method everytime as well, a program that does, lets say 50-100
 calls to 'getX()' that can skip INIT_METHOD_CALL + DO_FCALL_BY_NAME
 and instead just a FETCH_OBJ_R which is what should be after the
 fcall, micro optimization I know (been a while since I went into these
 parts so I might be a bit off though).
I knew this of course, but this is actually not related to this
specific readonly RFC

but if you are strict to this., then I'd like to say, this will
slowdown all FETCH_OBJ_R a bit, since this will need introduce a
condition to check whether a property is readonly..  only faster a
narrow case...

thanks

 I'm a huge +1 on this, good job Andrea!


 --
 regards,

 Kalle Sommer Nielsen
 ka...@php.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php