On Oct 11, 2012, at 4:59 AM, Clint Priest <cpri...@zerocue.com> wrote:

> Why is everyone so dead set against read-only and write-only?
> 
> 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).


If it can be used on normal properties as well (w/o the overhead of function 
calls) then: +1
Otherwise it would not be consistent to introduce it.

On the topic of consistency, could not see any other keyword in php that uses 
hyphen in it.


> 
> 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
> 



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

Reply via email to