On Fri, Oct 24, 2014 at 12:11 PM, Kalle Sommer Nielsen <ka...@php.net> wrote:
> Hi
>
> 2014-10-24 5:02 GMT+02:00 Xinchen Hui <larue...@php.net>:
>> Hey:
>>
>>    -1 on this.
>>
>>    Actually,   your example for explaining usage..
>>
>>     I don't see why it is must, add a getSize() will also meet the
>> needs, and more beatiful, as you can change $size to another name if
>> you like later.
>
> I disagree on your disagreement, while it is not a must, it does not
> make much sense that we are gonna call what essential is a function to
> return a value that is not changed in anyway during that call. It does
> not really perform a function, other than returning a value in 99% of
> all cases, and therefore it makes perfect sense to allow readonly
> properties in my mind.
>
> It does not really make the code beautiful to prefix it with 'get' and
> suffix it with '()' when you want such a value, it makes it
> consistent, yes, but else it is just bloat to my eyes.
so you prefer to expose the name of the property anywhere?

let's say you expose a readonly int value name iSize..

but later, the value also need to be a double,

then you also prefer add another dval? (since you can not simple
change ival name, since it was exposed)

>
> Internally it should also be a slightly be faster to not having to
> call a method everytime as well, a program that does, lets say 50-100
> calls to 'getX()' that can skip INIT_METHOD_CALL + DO_FCALL_BY_NAME
> and instead just a FETCH_OBJ_R which is what should be after the
> fcall, micro optimization I know (been a while since I went into these
> parts so I might be a bit off though).
I knew this of course, but this is actually not related to this
specific "readonly" RFC

but if you are strict to this., then I'd like to say, this will
slowdown all FETCH_OBJ_R a bit, since this will need introduce a
condition to check whether a property is readonly..  only faster a
narrow case...

thanks
>
> I'm a huge +1 on this, good job Andrea!
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Reply via email to