On Sat, Oct 20, 2012 at 9:29 AM, Amaury Bouchard <ama...@amaury.net> wrote: > read-only => final set null; > It begins to be verbose. > > As I said many times, why don't you want to use the "const" keyword? It > already exists and is pretty well understood by everybody. Could you maybe explain where exactly "const" would be used? Please don't forget that we do not use your "foo:bar" syntax, so where would the "const" go with the currently used syntax?
Anyway, I'd like to give a quick comment on read-only: I mainly don't like the keyword because it doesn't do what I expect it to do. When I first glanced over the RFC I thought that read-only was a way to define read-only properties (i.e. properties that can only be set via default value or in the constructor) along the lines of "public read-only $name = 'FooBar';". This is what the "readonly" modifier means in C# (which is the language the RFC is adopted from mainly). In C# readonly can *not* be added to properties with accessors, only to simple fields. With the current RFC / the original proposal "read-only" gets a completely different meaning. I think that the behavior of the modifier in C# is useful, whereas its behavior in the original accessors proposal is mostly pointless. I mean, why would you need to strictly enforce that a property is read-only throughout the inheritance hierarchy? From an interfacing (LSP) point of view it's not of importance whether an additional set accessor is added, as long as the get accessor stays. I would guess that "read-only" will be used about as much as "final" is used today. And "final" is nearly never used. That's why I really don't think that we need any kind of special syntax for this. If you do happen to be the rare case where you need to enforce the read-only-ness throughout the hierarchy, you can always use the "final private set()" approach (maybe even throwing an exception from it so you can't even access it from within the class). Everything else seems unnecessary to me and would only make things more complicated than necessary. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
