The usage of the syntax in C# is moderately unimportant. This is a
different language, and property accessors are part of numerous languages -
not just C#. That being said, it's not that big of a deal, as it seems that
most people are in a consensus that we do not want to to be adding any sort
of read only keyword.
The final keyword *is* used, especially in sizable OOP applications.
Claiming it supposedly isn't used very often anymore - even if it were true
- is not an excuse to exclude the "read-only"-esque functionality in this
RFC.
Amaury brings up an interesting point in that write-only essentially makes
the accessor a method. In my opinion, this needs to be further discussed as
to whether or not we do or do not need write-only. If there are no good
real-world implementations of it other than making a property act like a
method, then we should probably can that idea.
Read-only is still necessary, though in a different syntax. Being able to
set a "final"-esque functionality on the get property accessor function -
as to protect from certain cases, however few there may be - is, in my
opinion, an important, necessary piece of this RFC.
I think const has too many issues, and thus we shouldn't use it. When
setting a variable to a constant in PHP, it changes the way the variable is
called. From *$this->property* or *$variable* to *$this::property *or*variable
*. Even with const, we still have the same issue that we had with numerous
of the previous proposals:
> // Which one?
>
public $property {
> const get();
> const get;
> const get() {}
> final private get;
> final private get();
> final get NULL;
> }
>
> // This is what I assume Amaury would prefer, correct? We're not going
> with the colon syntax, though, so this example is out of the question...
>
public:const $property {
> set() { ... }
> }
>
Considering we aren't using the colon solution proposed by Amaury, const
still doesn't solve the solution and would just add confusion if we were to
implement it in whatever solution we come up with.
Let's look over our other past and current implementations and proposals:
> public $property {
> final get;
> final get();
> final get NULL;
> final private get() {} // RFC 1.2 Current Implemented Proposal
> }
>
> // And of course, from RFC 1.1
> public read-only $property {
> set() { ... }
> }
>
My top choice is *final get;*, which would work quite well and
non-ambiguously if we don't implement Nikita's proposed automatic accessor
functions or implement it in a noticeably different syntax.
It's the easiest to write, and it's pretty obvious that it isn't extendable
and doesn't actually do anything, and thus is arguably visually read-only.
My opinion of Clint's proposed *final get NULL;* is a bit meh - the null
keyword is just spat up on the code and the syntax is a bit too..
unfamiliar for my preference. It would make a lot more sense if it was *final
get = NULL;* but I don't think we should go that route.
On Sat, Oct 20, 2012 at 2:05 AM, Nikita Popov <nikita....@gmail.com> wrote:
> 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
>
>
