Yii Framework Forum: Protected Instead Of Private - Yii Framework Forum

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Protected Instead Of Private please please please! Rate Topic: -----

#1 User is offline   MetaYii 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 393
  • Joined: 07-October 08
  • Location:The Matrix

Posted 29 October 2012 - 12:43 PM

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:

private $_name;
private $_basePath;
private $_baseUrl;

into

protected $_name;
protected $_basePath;
protected $_baseUrl;
Ah! on-off, simplement!
0

#2 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,781
  • Joined: 17-January 09
  • Location:Russia

Posted 29 October 2012 - 01:28 PM

Any reason you want to change these after class was created?
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#3 User is offline   KonApaz 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 1,327
  • Joined: 21-February 11
  • Location:Greece

Posted 12 November 2012 - 06:19 PM

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.
Yii is the best php framework in the world!
find our demo Yii extension on www.webkit.gr
Is it post useful? please v++ ;)
0

#4 User is offline   pavlepredic 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 39
  • Joined: 30-August 11

Posted 14 November 2012 - 06:41 AM

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/p...eRecord.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?
0

#5 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,781
  • Joined: 17-January 09
  • Location:Russia

Posted 14 November 2012 - 03:08 PM

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.
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#6 User is offline   Maurizio Domba Cerin 

  • Yii - Yesss It Is !!!
  • Yii
  • Group: Yii Dev Team
  • Posts: 4,359
  • Joined: 12-October 09
  • Location:Croatia

Posted 15 November 2012 - 05:05 AM

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.
Find more about me.... btw. Do you know your WAN IP?
0

#7 User is offline   pavlepredic 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 39
  • Joined: 30-August 11

Posted 15 November 2012 - 05:50 AM

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 :)
0

#8 User is offline   Maurizio Domba Cerin 

  • Yii - Yesss It Is !!!
  • Yii
  • Group: Yii Dev Team
  • Posts: 4,359
  • Joined: 12-October 09
  • Location:Croatia

Posted 15 November 2012 - 06:09 AM

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.yiiframew...-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 :D
Find more about me.... btw. Do you know your WAN IP?
0

#9 User is offline   pavlepredic 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 39
  • Joined: 30-August 11

Posted 15 November 2012 - 12:04 PM

Deserves a poll, I think...
0

#10 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,781
  • Joined: 17-January 09
  • Location:Russia

Posted 15 November 2012 - 05:13 PM

I don't think so. We'll definitely not changing everything to protected. Some specific cases — yes, maybe.
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#11 User is offline   MetaYii 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 393
  • Joined: 07-October 08
  • Location:The Matrix

Posted 26 November 2012 - 11:54 AM

View Postsamdark, on 29 October 2012 - 01:28 PM, said:

Any reason you want to change these after class was created?


I want to extend from those Yii classes, but since properties are private, I can't use them in my extended class.
Ah! on-off, simplement!
0

#12 User is offline   MetaYii 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 393
  • Joined: 07-October 08
  • Location:The Matrix

Posted 26 November 2012 - 11:56 AM

View PostKonApaz, on 12 November 2012 - 06:19 PM, said:

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.



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.
Ah! on-off, simplement!
0

#13 User is offline   MetaYii 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 393
  • Joined: 07-October 08
  • Location:The Matrix

Posted 26 November 2012 - 11:57 AM

View PostMaurizio Domba, on 15 November 2012 - 05:05 AM, said:

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.


Not public but protected. I'll open the ticket. Thanks.
Ah! on-off, simplement!
0

#14 User is offline   MetaYii 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 393
  • Joined: 07-October 08
  • Location:The Matrix

Posted 26 November 2012 - 12:11 PM

Opened an issue: https://github.com/y...yii/issues/1759
Ah! on-off, simplement!
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users