I find a bit weird that most properties are private instead of protected in the case of classes such as CTheme, which could need to be modified in most cases. Could you please change:
[b]private[/b] $_name;
[b]private[/b] $_basePath;
[b]private[/b] $_baseUrl;
into
[b]protected[/b] $_name;
[b]protected[/b] $_basePath;
[b]protected[/b] $_baseUrl;Any reason you want to change these after class was created?
As we remind protected-private-public
if you want to provide no access directly from other classes then using private
I you are going to extend the class and having access to this variables from it then use protected
In other cases use public
So, In CTheme case, there is no reason to modify this variables after of created instance.
Finally, this prevents you to set this variables by accident.
I also have a hard time understanding why Yii community chooses to use private instead of protected properties. This approach makes it very difficult to extend framework classes. I understand the need for a clean interface, but when you make all those properties private, you’re basically discouraging developers from extending your classes. Often, when I inherit from Yii classes, I have to re-declare some properties in the child class (see here for example: https://github.com/pavlepredic/Yii-dynamic-active-record/blob/master/DynamicActiveRecord.php#L26)
Protected variables offer the same level of encapsulation, while allowing developers to tinker with class internals when extending. You can’t possibly envision all the ways in which your class may be used at the time of writing it, so why not err on the side of exposing too much, rather than too little?
It’s not the same level of incapsulation at all. If property made protected once we have to keep it in the API. If it’s private we can rename it or delete it easily.
As a general rule, if anybody have a need to extend a core class and to use any private property, feel free to open a github issue and ask for it to be made public… but please give a reasonable use-case for this… we already changed few properties this way.
The way I see it, it’s only a matter of convention. You choose to use private properties, because that way you feel safer that you won’t break anything when changing implementation details. I know that this is a complex issue, and I do not intend to give lectures to people who know much more about computer science than I do. I’m just voicing my opinion, which is that extending Yii classes can sometimes be a pain. If you were to change all private properties to protected and then continue treating them as if they were private, you would achieve the same goal, while retaining more lenience when extending. Only public properties and methods comprise class interface, so if I choose to rely on a protected property in my child class, I do so at my own risk. Just my 2 cents, I might be totally wrong 
The private/public issue is a never-ending discussion that has already too many topics on this forum…
Check this one for example: http://www.yiiframework.com/forum/index.php/topic/27523-why-private-scope/
fact is that there are reasons why not all attributes are public… and again re-read my previous post… if there is a good reason or use-case for a private property to be changed to public… just ask and it will be done. If not we are just talking the talk and not walking the talk 
Deserves a poll, I think…
I don’t think so. We’ll definitely not changing everything to protected. Some specific cases — yes, maybe.
I want to extend from those Yii classes, but since properties are private, I can’t use them in my extended class.
But I can’t extend CTheme to create my own theme handler. That’s the problem. Yii claims to be extensible, but can not be extended without modifiying some core classes, and those changes will need to be redone if you upgrade Yii. That’s a big issue to me.
Not public but protected. I’ll open the ticket. Thanks.