Dear internals,
I really like the way Nikita describes the implementation. It is very
consistent and easy to read. At least for me it is.
I must say I'm very excited to see this implementation coming to PHP
Kind regards,
Chris van Dam
Op 20-10-12 11:52 schreef Nikita Popov <nikita....@gmail.com>:
>On Sat, Oct 20, 2012 at 11:31 AM, Jazzer Dane <tbprogram...@gmail.com>
>wrote:
>> 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.
>Firstly, I didn't make that claim out of thin air, I actually checked
>how many final methods are used in ZF and Symfony (which are my usual
>reference projects due to their large size) and from that concluded
>that "nearly never" is a very accurate description. It could obviously
>be that those two projects are somehow special and everyone else uses
>large amounts of final methods ;)
>
>Secondly, low anticipated use is actually a very good reason to
>exclude functionality. One shouldn't add features from which you know
>right from the start that nearly no-one will use them.
>
>Thirdly, I don't want to exclude the possibility of enforcing
>read-only-ness through the hierarchy. I just don't want to provide a
>dedicated syntax for such an edge case. As already mentioned, there
>already are sufficiently simple ways to do this:
>
> // read-only for all classes in the hierarchy, only the current one
>can read
> final private set();
> // absolutely read-only
> final private set() { throw new ReadonlyPropertyException; }
>
>The latter is even rather clear about the intention ;)
>
>> 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.
>Not sure where you got that, but automatic accessor implementations
>are not my idea, they were part of the original proposal. I wanted to
>remove them, but later we found that they are necessary for various
>aspects of the RFC, in particular asymmetric accessor visibility
>(public $foo { get; protected set; }). Unless you want to drop that
>too automatic implementations have to stay.
>
>Nikita
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>
E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
entity to whom it is addressed and others authorized to receive it. The use of
it by others is prohibited. Trace is neither liable for the proper and complete
transmission of the information contained in this communication nor for any
delay in its receipt.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
