"Zeev Suraski" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> ...
> Regarding whether it's an access level or a modifier, I think that an
> access level is better since you don't have to explain a matrix of 6
> different behaviors (including one that doesn't make sense, but still
> requires an explanation), only one more access level. I think we can
> definitely give up the equivalent of 'readonly protected', and tell people
> to use protected and restrain themselves in those rare cases where it's
> needed and use regular protected or __set(). When we make this decision,
> though, it means that we won't be adding the equivalent of 'readonly
> protected' in the future either, including when people come along and
> present a use case where it'd be great to use it.
>
> Zeev
I don't need this feature, so I'm not suggestion anything just because I'd
prefer it that way myself. I'm perfectly happy writing setters and getters.
The only reason of my post was that I anticipate disappointment in the long
run when, as you confirm yourself, "readonly protected" will become
practically impossible (besides which, going beyond ppp just seems a little
ugly, but I'm sure that's just a matter of taste).
I don't really see the huge deal in that a beginner has to be able to
understand every bit of code. That same problem exists with other languages
where beginners will have big problems diving into complex code (very much
including syntax related complexity, like with c++ templates, macros, ...).
The only thing I fear is disappointment in the long run really, because an
irriversible unlucky decision was made (magic quotes, parameter order of
certain functions).
In fact, if you want the easiest solution, I actually think the wrong idea I
had about c++ access levels could prove to be useful:
What if access levels only mean anything to writing to data members, while
all data members are publicly readable?
<?php
class Foo
{
private $bar = 5;
}
$foo = new Foo();
echo $foo->bar; // prints 5
$foo->bar = 4; // error
?>
I think backwards compatibility would likely be alright, performance will be
fine, there will be no extra keyword, no extra access level, and no need for
getter functions. Just an idea.
Regards,
Ron
> At 11:44 16/05/2006, Ron Korving wrote:
>>This is absolutely true. Besides, adding a new access level automatically
>>implies that you'll probably never be able to extend it to protected as
>>well, because you'd need yet another access level and I really doubt
>>people
>>are going to want to do that. But at that point, it would be too late to
>>revert back to a readonly keyword, since the whole world is using the new
>>publicly readable access level already. Choosing to go for a new access
>>level can turn out to be a really big mistake in the long run.
>>
>>Like you, I don't see why a 'readable' keyword should make things any more
>>complicated for beginners, because indeed, it is optional and beginners
>>will
>>simply not use it. To me, this only shows the strength of PHP: suitable
>>for
>>beginners and suitable for the enterprise.
>>
>>Ron
>>
>>
>>"Jason Garber" <[EMAIL PROTECTED]> schreef in bericht
>>news:[EMAIL PROTECTED]
>> > Hello Zeev,
>> >
>> > In the same way that public readonly properties would be useful
>> > from the global scope, protected readonly properties would be just
>> > as useful to those of us who spend their php-lives writing base
>> > classes (like me) for others to extend and use.
>> >
>> > I would imagine that the Zend Framework will encounter the
>> > (performance based) need for this eventually - I already have.
>> >
>> > That being said, an access level that means "public readonly" would
>> > be very good - but taking it the whole way would be a lot better.
>> >
>> > Considering that it is an optional keyword, and will only be used
>> > where __get(), __set() used to be used - it won't confuse the end
>> > users who do not care about it. (get/set is a lot more complex).
>> >
>> > Thanks!
>> >
>> > --
>> > Best regards,
>> > Jason mailto:[EMAIL PROTECTED]
>> >
>> > Monday, May 15, 2006, 2:15:50 PM, you wrote:
>> >
>> > ZS> I have to say that in second thought (after realizing what you
>> > really
>> > ZS> meant) it sounds like a very useful feature.
>> >
>> > ZS> The main thing that worries me is the complexity to the end user,
>> > ZS> which is already in a pretty bad shape as it is today, and many
>> > ZS> people here care very little about it, because they can't relate to
>> > ZS> beginners and average developers. Private/protected/public is a
>> > ZS> challenge to many of them (not the theory, real world situations),
>> > ZS> doubling complexity with a modifier is not a good idea.
>> >
>> > ZS> In order to push complexity down I'd avoid making this yet another
>> > ZS> modifier, and in fact make this an access level, on par with
>> > ZS> private/protected/public, that would behave like public, except for
>> > ZS> when outside the object scope (i.e., have it between protected and
>> > ZS> public). One of the trickey things would be finding an acceptable
>> > ZS> name, since 'readonly' implies something which this variable isn't
>> > ZS> (it's very much writable, from the right places). Maybe something
>> > ZS> like 'visible' (of course preferably we need to find something that
>> > ZS> begins with 'p'...)
>> >
>> > ZS> Zeev
>> >
>> > ZS> At 02:35 12/05/2006, Jason Garber wrote:
>> >>>Hello internals,
>> >>>
>> >>> __get() and __set() are great, but 90% of the time, I find myself
>> >>> using them to create public readonly properties.
>> >>>
>> >>> The only problem with this is it is horridly inefficient, consuming
>> >>> at least 1 function call and one switch statement (or equiv) per
>> >>> property read.
>> >>>
>> >>> Would it be possible to create a new object property attribute:
>> >>> readonly
>> >>>
>> >>> class xx
>> >>> {
>> >>> readonly $bar;
>> >>> }
>> >>>
>> >>> $o = new xx();
>> >>>
>> >>> $o->bar = 10;
>> >>> >>> FATAL ERROR
>> >>>
>> >>>
>> >>> This way, PHP would allow reading (as if it were public), but only
>> >>> allow writing from within the class.
>> >>>
>> >>> I think it could really boost performance of complicated
>> >>> application
>> >>> logic that wishes to enforce good visibility.
>> >>>
>> >>> Comments?
>> >>>
>> >>> PS. What brought this up was some serious performance issues in a
>> >>> piece of code that I am working with - most of which can be tied
>> >>> back to __get() performance.
>> >>>
>> >>>--
>> >>>Best regards,
>> >>> Jason Garber mailto:[EMAIL PROTECTED]
>> >>> IonZoft, Inc.
>> >>>
>> >>>--
>> >>>PHP Internals - PHP Runtime Development Mailing List
>> >>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>--
>>PHP Internals - PHP Runtime Development Mailing List
>>To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
