2012/10/11 Clint Priest <cpri...@zerocue.com>
> Why is everyone so dead set against read-only and write-only?
>
my opinion
1.
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
And now? That this is even possible is reason enough for me. Especially now
the engine must take care about this inconsistency (over the whole
inheritance tree). It feels unnecessary.
2. This new keyword is unnecessary
3. Don't know, if it's just my, but I find it slightly annoying, that this
discussion even exists. The engine already knows every token, that is
required to implement this RFC, so whats this all about? This way it will
not be ready for 5.5 and I guess not for 5.6 either...
4. It is more readable, ok, but it is not that much and I think it's just
to less to say "Lets rewrite everything and make everything more complex
(see 1.) and such!"
>
> I could not disagree more with you on what is "pretty" and "readable".
>
> To me:
>
> public read-only $hours {
> get { ... }
> }
>
> Is infinitely more readable and understandable than:
>
> public $hours {
> get() { ... }
> private final set($value) { ... }
> }
>
> The latter implies that it can be "set" within the right context
> (internally to the class), which is precisely the opposite of what is
> desired (read only).
>
No, it's not the opposite, but only slightly more loosely: It only says "It
is 'set'able from within this concrete class, but it is read-only from
_everywhere_ else", what is in most cases that, what is _really_ wanted. If
you don't want to set it, don't set it. It is your class. And for everyone
else, it's really read-only.
>
> From: Jazzer Dane [mailto:tbprogram...@gmail.com]
> Sent: Wednesday, October 10, 2012 9:18 PM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
>
> This all sounds about right.
>
> In regards to #4 - read-only/write-only:
> I think that, from a "pretty syntax" point of view, private final set() {}
> and private final get() {} are definitely our best bets. But... from a
> logical point of view, I prefer read-only/write-only.
>
> private final get() {} is technically saying it will always return null.
> private final set() {} is technically saying that setting doesn't do
> anything - but it still works.
>
> But I don't see any sane scenario where someone would want to do the
> above. Therefore, it may just be best to use them in place of the currently
> proposed read-only/write-only.
> On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest <cpri...@zerocue.com<mailto:
> cpri...@zerocue.com>> wrote:
> Okay, I would like this to be the last time there are revisions to this
> RFC.
>
> To sum up the last few days of conversations, I have these down as points
> of contention:
>
> 1. Accessor functions should not be present on the object and callable
> directly, for example, $o->__getHours() should not be allowed.
> 2. Preferred syntax for accessors should be "public set($value) { ... }"
> with no "magic" $value (with possible type hinting)
> 3. Automatically implemented get; set; with auto-backing field should be
> eliminated as this is not necessary for PHP and is confusing most everyone.
> 4. read-only / write-only keywords, keep them or get rid of them? There
> is no directly suitable replacement but I believe a private final set() { }
> will take care of it, even though it much more verbose.
> 5. Error handling for thrown exceptions should be made more appropriate
> for accessors
> 6. The "truth" of reflection. Should it reveal details internal to how
> PHP works on the inside or should it reflect the way PHP presents it as
> options?
>
> Did I miss anything?
>
>
> I will come up with some way for people to vote on the issues at hand and
> we can cast our votes and be done with it, then I will finish the project
> and get it out the door.
>
> -Clint
>
>
--
github.com/KingCrunch
