Hi, In recent commits has been moved most protected methods and properties to private. I think it's completely unnecessary step. In PHP I dislike the keywords private and final (I hate their implementation in PHP). Why? Private methods prevent reuse of code and keyword final kills reuse of code. Real private methods do'nt exist in Python and Ruby (it is possible to callprivate methods or overload them). In my opinion, framework should have almost no private methods. I don't want to use the class composition for every little thing.
My tip: how to change value of private property in PHP 5.3 > ?
class A { private $a;
public function __construct() { $this->a = new Foo(); //only one poorly designed place in class }
}
class B extends A { public function __construct() { $reflection = new ReflectionProperty('A', 'a'); $reflection->setAccessible(true); $reflection->setValue($this, new FooBar()); }
there is a simple reasoning for making as much as possible private and
there was a lengthy discussion.
the reasoning goes something like this:
public and protected methods and properties are accessible for
developers using the framework. their code becomes dependant on that
interface.
to avoid breaking BC these accessible methods and properties can not
be changed for future releases.
private methods however can be changed as no code other than framework
code can use them.
so the more public/protected the symfony interface gets the more api
code needs to be maintained and is in fact set in stone.
the current approach is to make as much as possible private but to
reopen some of the code upon request when there is a good reasoning.
cheers
/christian
On 9 Mrz., 08:29, Martin Hasoň <martin.ha...@gmail.com> wrote:
> Hi,
> In recent commits has been moved most protected methods and properties to
> private. I think it's completely unnecessary step. In PHP I dislike the
> keywords private and final (I hate their implementation in PHP). Why?
> Private methods prevent reuse of code and keyword final kills reuse of code.
> Real private methods do'nt exist in Python and Ruby (it is possible to callprivate methods or
> overload them). In my opinion, framework should have almost no private methods.
> I don't want to use the class composition for every little thing.
> My tip: how to change value of private property in PHP 5.3 > ?
> class A {
> private $a;
> public function __construct() {
> $this->a = new Foo(); //only one poorly designed place in class
> }
> }
> class B extends A {
> public function __construct() {
> $reflection = new ReflectionProperty('A', 'a');
> $reflection->setAccessible(true);
> $reflection->setValue($this, new FooBar());
> }
This is essentially killing inheritance for thoose classes. This means that the framework can only be extended in the ways that core devs want. So if i wanted to readd the request format magic for my projects i wouldnt be able to do that.
> This is essentially killing inheritance for thoose classes. This means that the framework can only be extended in the ways that core devs want. So if i wanted to readd the request format magic for my projects i wouldnt be able to do that.
Its a question of maintainability. We want to provide a reliable API. By making everything protected we basically have to maintain a very large API. Worse yet, the user has no clue what extension points we recommend and which we do not. The end result is that you quickly cannot change anything anymore in the core, since users will use various different extension points to achieve the same.
Now in the past I have also been violently opposed to the above practice. However, these days we have several benefits: - git makes it easy to fork - git makes it easy for others to contributes patches to open up API's in specific places - even if for some reason the patch is not accepted, with git its easier to keep your custom fork in sync
The other alternative is breaking BC in minor releases (aka 2.1) so I think going to private by default is the better approach. Again on a case by case basis we will then open up the API for inheritance.
> On 09.03.2011, at 10:16, Henrik Bjornskov wrote:
> > This is essentially killing inheritance for thoose classes. This means > that the framework can only be extended in the ways that core devs want. So > if i wanted to readd the request format magic for my projects i wouldnt be > able to do that.
> Its a question of maintainability. We want to provide a reliable API. By > making everything protected we basically have to maintain a very large API. > Worse yet, the user has no clue what extension points we recommend and which > we do not. The end result is that you quickly cannot change anything anymore > in the core, since users will use various different extension points to > achieve the same.
> Now in the past I have also been violently opposed to the above practice. > However, these days we have several benefits: > - git makes it easy to fork > - git makes it easy for others to contributes patches to open up API's in > specific places > - even if for some reason the patch is not accepted, with git its easier to > keep your custom fork in sync
> The other alternative is breaking BC in minor releases (aka 2.1) so I think > going to private by default is the better approach. Again on a case by case > basis we will then open up the API for inheritance.
> regards, > Lukas Kahwe Smith > m...@pooteeweet.org
> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com
> You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en
For API is only public visibility (see http://api.symfony-reloaded.org/master/). Protected visibility is for all others. Private visibility is only for very very special method. Public visiblity is for user, protected visibility is for programmer and private visibility is for black box. For example framework Django doesn't have a private method.
For people that disagree, read up on http://en.wikipedia.org/wiki/Open/closed_principle <http://en.wikipedia.org/wiki/Open/closed_principle> <http://en.wikipedia.org/wiki/Open/closed_principle>Allowing all properties and methods to be hijacked in subclasses and allowing subclass anything opens the system to modification, as any of the core system behavior can be changed. The correct approach is to provide contracts for extension (interfaces) and concrete closed implementations that are well-tested and work, and can be changed internally at any time, without breaking user-land code that interacts with them (think refactoring).
If user-land code relies on some internal behavior however, the whole system is much more error prone with any change to the core class, as it ripples through all of its descendants.
My advice to all framework users is to provide alternative implementations of pre-defined interfaces, instead than relying on overloading of core classes. Same applies to mocking - mock interfaces and not actual implementations.
Final and private are underused in PHP, which is the result of programmers not thinking of providing explicit ways to extend their framework. Instead of defining extension points, they simply leave the whole framework open to modification, which leads to unexpected behavior. The fact that methods and properties are becoming declared as private means that the framework is in the stage of its maturity, where we think of opening legit ways for its extension, while eliminating possibility of hacks.
On Wed, Mar 9, 2011 at 5:42 AM, Martin Hasoň <martin.ha...@gmail.com> wrote: > For API is only public visibility (see > http://api.symfony-reloaded.org/master/). Protected visibility is for all > others. Private visibility is only for very very special method. Public > visiblity is for user, protected visibility is for programmer and private > visibility is for black box. For example framework Django doesn't have a > private method.
> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com
> You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en
Just to give an example, Doctrine 2 has almost no protected only private variables and strictly prevents inheritance in many cases:
What this enabled us to do in our development of 2.1 is to refactor the internals of many of our central classes to allow for much better performance and tons of new features that needed adjusting central parts of the Doctrine classes.
With protected variables all this would not be possible, because we would have to break BC.
There are very real benefits of the closed principle even for frameworks and if they are maintained very well and bugs get fixed fast then there is no problem. Frameworks like ZF need protected stuff because frankly most of ZF components go into production releases where an "alpha" tag would be useful. However the level of detail that went into the Symfony API and also compared to other frameworks the "few tasks" it tries to solve (focus on the relevant!) using private properties is actually a positive step towards future enhancements of the framework.
One HUGE benefit here is the DI Container, almost everything in Symfony has an interface. Just exchange the whole implementation! Yes you need to copy the code, yes its more ocmplex to maintain FOR YOU. but in contrast, the framework is much easier to maintain for us core developers and this will benefit EVERYONE in the long run.
greetings, Benjamin
On Wed, 9 Mar 2011 17:19:55 -0500, Bulat Shakirzyanov
<mallluh...@gmail.com> wrote: > This change is for the best.
> For people that disagree, read up on > http://en.wikipedia.org/wiki/Open/closed_principle > <http://en.wikipedia.org/wiki/Open/closed_principle> > <http://en.wikipedia.org/wiki/Open/closed_principle>Allowing all properties > and methods to be hijacked in subclasses and allowing subclass anything > opens the system to modification, as any of the core system behavior can be > changed. > The correct approach is to provide contracts for extension (interfaces) and > concrete closed implementations that are well-tested and work, and can be > changed internally at any time, without breaking user-land code that > interacts with them (think refactoring).
> If user-land code relies on some internal behavior however, the whole > system > is much more error prone with any change to the core class, as it ripples > through all of its descendants.
> My advice to all framework users is to provide alternative implementations > of pre-defined interfaces, instead than relying on overloading of core > classes. > Same applies to mocking - mock interfaces and not actual implementations.
> Final and private are underused in PHP, which is the result of programmers > not thinking of providing explicit ways to extend their framework. Instead > of defining extension points, they simply leave the whole framework open to > modification, which leads to unexpected behavior. The fact that methods and > properties are becoming declared as private means that the framework is in > the stage of its maturity, where we think of opening legit ways for its > extension, while eliminating possibility of hacks.
> Best,
> On Wed, Mar 9, 2011 at 5:42 AM, Martin Hasoň <martin.ha...@gmail.com> > wrote:
>> For API is only public visibility (see >> http://api.symfony-reloaded.org/master/). Protected visibility is for all >> others. Private visibility is only for very very special method. Public >> visiblity is for user, protected visibility is for programmer and private >> visibility is for black box. For example framework Django doesn't have a >> private method.
>> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com
>> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfony-devs@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-devs+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en
OK. But I don't understand one thing. The API (Symfony2 or Doctrine2) consists only of public methods. Where is the break BC if I change the protected method?
Yes the DI Container is huge benefit, but I don't want copy the code (copy and paste programming is antipattern).
> OK. But I don't understand one thing. The API (Symfony2 or Doctrine2) > consists only of public methods. Where is the break BC if I change the > protected method?
> Yes the DI Container is huge benefit, but I don't want copy the code > (copy and paste programming is antipattern).
Providing protected methods means the class is intended to be inheritable (this is what protected is for). So using protected everywhere means you allow the user to extend the core classes and changing the protected methods would break the child classes. The only real internal implementation is a private implementation.
If you can extend the class, then you should be using `protected`.
Private, IMO, isn't entirely necessary and is only being used to try
and stop bad practices of those utilizing an open-source product.
Symfony is well designed, but there's no need to bind the hands of
whoever chooses to extend code for their own purposes.
I understand both sides to this debate. In the same way that we use
getters/setters to avoid direct access to internals of a class via
public properties, we're now inheriting classes to go the same route
when they should share ownership.
To me, changing "protected" to "private" is spending cycles solving a
problem that either doesn't really exist, or isn't the framework's
problem to solve.
My $0.02 & change :)
--
Eric Clemmons
On Mar 9, 4:19 pm, Bulat Shakirzyanov <mallluh...@gmail.com> wrote:
> For people that disagree, read up onhttp://en.wikipedia.org/wiki/Open/closed_principle > <http://en.wikipedia.org/wiki/Open/closed_principle>
> <http://en.wikipedia.org/wiki/Open/closed_principle>Allowing all properties
> and methods to be hijacked in subclasses and allowing subclass anything
> opens the system to modification, as any of the core system behavior can be
> changed.
> The correct approach is to provide contracts for extension (interfaces) and
> concrete closed implementations that are well-tested and work, and can be
> changed internally at any time, without breaking user-land code that
> interacts with them (think refactoring).
> If user-land code relies on some internal behavior however, the whole system
> is much more error prone with any change to the core class, as it ripples
> through all of its descendants.
> My advice to all framework users is to provide alternative implementations
> of pre-defined interfaces, instead than relying on overloading of core
> classes.
> Same applies to mocking - mock interfaces and not actual implementations.
> Final and private are underused in PHP, which is the result of programmers
> not thinking of providing explicit ways to extend their framework. Instead
> of defining extension points, they simply leave the whole framework open to
> modification, which leads to unexpected behavior. The fact that methods and
> properties are becoming declared as private means that the framework is in
> the stage of its maturity, where we think of opening legit ways for its
> extension, while eliminating possibility of hacks.
> Best,
> On Wed, Mar 9, 2011 at 5:42 AM, Martin Hasoň <martin.ha...@gmail.com> wrote:
> > For API is only public visibility (see
> >http://api.symfony-reloaded.org/master/). Protected visibility is for all
> > others. Private visibility is only for very very special method. Public
> > visiblity is for user, protected visibility is for programmer and private
> > visibility is for black box. For example framework Django doesn't have a
> > private method.
> > --
> > If you want to report a vulnerability issue on symfony, please send it to
> > security at symfony-project.com
> > You received this message because you are subscribed to the Google
> > Groups "symfony developers" group.
> > To post to this group, send email to symfony-devs@googlegroups.com
> > To unsubscribe from this group, send email to
> > symfony-devs+unsubscribe@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/symfony-devs?hl=en
You have to also consider what this change forces us to do. Instead of just solving the inheritance and extension problem by whoring out our API and opening everything up we will have to specifically design for inheritance and extension points. This will result in a much better experience for everyone .You will have clear ways to extend and inherit things that are designed for it, and we will have a much easier time maintaining and evolving the internals of the code because we won't be breaking BC every move we make. It may be hard to see now but fruits from this change will definitely be apparent later in the life of Symfony2.
On Wed, Mar 9, 2011 at 7:23 PM, ericclemmons <e...@smarterspam.com> wrote: > If you can extend the class, then you should be using `protected`. > Private, IMO, isn't entirely necessary and is only being used to try > and stop bad practices of those utilizing an open-source product.
> Symfony is well designed, but there's no need to bind the hands of > whoever chooses to extend code for their own purposes.
> I understand both sides to this debate. In the same way that we use > getters/setters to avoid direct access to internals of a class via > public properties, we're now inheriting classes to go the same route > when they should share ownership.
> To me, changing "protected" to "private" is spending cycles solving a > problem that either doesn't really exist, or isn't the framework's > problem to solve.
> My $0.02 & change :) > -- > Eric Clemmons
> On Mar 9, 4:19 pm, Bulat Shakirzyanov <mallluh...@gmail.com> wrote: > > This change is for the best.
> > For people that disagree, read up onhttp:// > en.wikipedia.org/wiki/Open/closed_principle > > <http://en.wikipedia.org/wiki/Open/closed_principle> > > <http://en.wikipedia.org/wiki/Open/closed_principle>Allowing all > properties > > and methods to be hijacked in subclasses and allowing subclass anything > > opens the system to modification, as any of the core system behavior can > be > > changed. > > The correct approach is to provide contracts for extension (interfaces) > and > > concrete closed implementations that are well-tested and work, and can be > > changed internally at any time, without breaking user-land code that > > interacts with them (think refactoring).
> > If user-land code relies on some internal behavior however, the whole > system > > is much more error prone with any change to the core class, as it ripples > > through all of its descendants.
> > My advice to all framework users is to provide alternative > implementations > > of pre-defined interfaces, instead than relying on overloading of core > > classes. > > Same applies to mocking - mock interfaces and not actual implementations.
> > Final and private are underused in PHP, which is the result of > programmers > > not thinking of providing explicit ways to extend their framework. > Instead > > of defining extension points, they simply leave the whole framework open > to > > modification, which leads to unexpected behavior. The fact that methods > and > > properties are becoming declared as private means that the framework is > in > > the stage of its maturity, where we think of opening legit ways for its > > extension, while eliminating possibility of hacks.
> > Best,
> > On Wed, Mar 9, 2011 at 5:42 AM, Martin Hasoň <martin.ha...@gmail.com> > wrote: > > > For API is only public visibility (see > > >http://api.symfony-reloaded.org/master/). Protected visibility is for > all > > > others. Private visibility is only for very very special method. Public > > > visiblity is for user, protected visibility is for programmer and > private > > > visibility is for black box. For example framework Django doesn't have > a > > > private method.
> > > -- > > > If you want to report a vulnerability issue on symfony, please send it > to > > > security at symfony-project.com
> > > You received this message because you are subscribed to the Google > > > Groups "symfony developers" group. > > > To post to this group, send email to symfony-devs@googlegroups.com > > > To unsubscribe from this group, send email to > > > symfony-devs+unsubscribe@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/symfony-devs?hl=en
> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com
> You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en
> You have to also consider what this change forces us to do. Instead of just solving the inheritance and extension problem by whoring out our API and opening everything up we will have to specifically design for inheritance and extension points. This will result in a much better experience for everyone .You will have clear ways to extend and inherit things that are designed for it, and we will have a much easier time maintaining and evolving the internals of the code because we won't be breaking BC every move we make. It may be hard to see now but fruits from this change will definitely be apparent later in the life of Symfony2.
exactly ... this change doesnt mean "no inheritance" .. it means carefully guided and designed inheritance extension points. less guessing about which of the 3-5 different possible ways to do something to choose. more consistency across Bundles follows naturally.
as a result of stopping this gigantic kitten slaughter we might end up with a kitten plague ;)
+1 Lukas + Jonathan's comments, specifically in regards to reducing BC
breaks and reducing extension points to a manageable number.
So, the code in the future will have a lot less of manipulation of
"$this->fooObject", but rather manipulating "$this->getFooObject()"
because of the constrained API?
You're right. Down the line, forcing a gateway to object properties
will prove beneficial, especially if the getter does something more
than simply returning the property value, such as lazy-loading an
object or dispatching an event.
Thanks for the clarification, fellows!
On Mar 10, 11:10 am, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
> > You have to also consider what this change forces us to do. Instead of just solving the inheritance and extension problem by whoring out our API and opening everything up we will have to specifically design for inheritance and extension points. This will result in a much better experience for everyone .You will have clear ways to extend and inherit things that are designed for it, and we will have a much easier time maintaining and evolving the internals of the code because we won't be breaking BC every move we make. It may be hard to see now but fruits from this change will definitely be apparent later in the life of Symfony2.
> exactly ... this change doesnt mean "no inheritance" .. it means carefully guided and designed inheritance extension points. less guessing about which of the 3-5 different possible ways to do something to choose. more consistency across Bundles follows naturally.
> as a result of stopping this gigantic kitten slaughter we might end up with a kitten plague ;)
> regards,
> Lukas Kahwe Smith
> m...@pooteeweet.org
interesting read. An example that comes to mind are bind() vs.
doBind(), and save() vs. doSave() in the object form classes, where
only the do* methods are supposed to be overriden, yet that nugget of
wisdom is only in the phpdoc comment and is easily overlooked, so lots
of code I see has the bind() & save() methods overridden directly.
+1 for private.
Daniel
On Mar 10, 9:29 am, ericclemmons <e...@smarterspam.com> wrote:
> +1 Lukas + Jonathan's comments, specifically in regards to reducing BC
> breaks and reducing extension points to a manageable number.
> So, the code in the future will have a lot less of manipulation of
> "$this->fooObject", but rather manipulating "$this->getFooObject()"
> because of the constrained API?
> You're right. Down the line, forcing a gateway to object properties
> will prove beneficial, especially if the getter does something more
> than simply returning the property value, such as lazy-loading an
> object or dispatching an event.
> Thanks for the clarification, fellows!
> On Mar 10, 11:10 am, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
> > On 10.03.2011, at 18:05, Jonathan Wage wrote:
> > > You have to also consider what this change forces us to do. Instead of just solving the inheritance and extension problem by whoring out our API and opening everything up we will have to specifically design for inheritance and extension points. This will result in a much better experience for everyone .You will have clear ways to extend and inherit things that are designed for it, and we will have a much easier time maintaining and evolving the internals of the code because we won't be breaking BC every move we make. It may be hard to see now but fruits from this change will definitely be apparent later in the life of Symfony2.
> > exactly ... this change doesnt mean "no inheritance" .. it means carefully guided and designed inheritance extension points. less guessing about which of the 3-5 different possible ways to do something to choose. more consistency across Bundles follows naturally.
> > as a result of stopping this gigantic kitten slaughter we might end up with a kitten plague ;)
Yes, interesting discussion. What I understood is that symfony2 is such a sophisticated framework that every possible use case is already taken care of, and because of that everything should be private/final. If you are sure that's the case... In my opinion having to copy the code of a class to add a small feature is very bad for maintainability (yes, the framework user's, not the framwork developer's). In case of a security problem, this leads to sites patched late or not at all. Why not just put a sentence in the documentation: "protected properties/methos are not part of the API and can be changed any time"?
> interesting read. An example that comes to mind are bind() vs. > doBind(), and save() vs. doSave() in the object form classes, where > only the do* methods are supposed to be overriden, yet that nugget of > wisdom is only in the phpdoc comment and is easily overlooked, so lots > of code I see has the bind() & save() methods overridden directly.
> +1 for private.
> Daniel
> On Mar 10, 9:29 am, ericclemmons <e...@smarterspam.com> wrote: >> +1 Lukas + Jonathan's comments, specifically in regards to reducing BC >> breaks and reducing extension points to a manageable number.
>> So, the code in the future will have a lot less of manipulation of >> "$this->fooObject", but rather manipulating "$this->getFooObject()" >> because of the constrained API?
>> You're right. Down the line, forcing a gateway to object properties >> will prove beneficial, especially if the getter does something more >> than simply returning the property value, such as lazy-loading an >> object or dispatching an event.
>> Thanks for the clarification, fellows!
>> On Mar 10, 11:10 am, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
>>> On 10.03.2011, at 18:05, Jonathan Wage wrote:
>>>> You have to also consider what this change forces us to do. Instead of just solving the inheritance and extension problem by whoring out our API and opening everything up we will have to specifically design for inheritance and extension points. This will result in a much better experience for everyone .You will have clear ways to extend and inherit things that are designed for it, and we will have a much easier time maintaining and evolving the internals of the code because we won't be breaking BC every move we make. It may be hard to see now but fruits from this change will definitely be apparent later in the life of Symfony2.
>>> exactly ... this change doesnt mean "no inheritance" .. it means carefully guided and designed inheritance extension points. less guessing about which of the 3-5 different possible ways to do something to choose. more consistency across Bundles follows naturally.
>>> as a result of stopping this gigantic kitten slaughter we might end up with a kitten plague ;)
>>> regards, >>> Lukas Kahwe Smith >>> m...@pooteeweet.org
> Yes, interesting discussion. > What I understood is that symfony2 is such a sophisticated framework > that every possible use case is already taken care of, and because of > that everything should be private/final. If you are sure that's the case...
no we are not sure that this is the case. so we will review requests to open the API on a case by case basis. we are just reversing from defaulting to protected to defaulting to private.
> Why not just put a sentence in the documentation: "protected > properties/methos are not part of the API and can be changed any time"?
because that would also not be correct, since we do have places where we invite users to inherit and reuse methods.
+1 for privates. +1 for good usage of the final keyword as it can be a great tool to preserve code consistency and to control "what" the developer can override. A great example is for final constructors which call explicitly a initialize() method to allow developer to do "extra" stuff.
+1 because it's a pain in the ass when you start a huge project with a version of a framework and when at some point you want to update your vendors with the last releases to benefit of all the new stuff and bugfix and improvements and all. How many of us just said one day : "Hum it's working well as it is, why touching anything ? Just let it on this 2 years ago release, as long as it works :)"
"Design by contract" ! That's the Symfony 2 approach here, and that's what the end-user should do ! The DIC is a great tool. That's the best approach for the developer on so many points and particulary to have total control of its code, instead of overriding all he sees. (Take Magento for instance, it's a nightmare).
I just want to be able to update my vendors at any time, and don't want to be stressed about it. I just want to read the change log and say "Yeah cool stuff. Hum, nice the bug is finally fixed !", and then play around with my Care Bears friends :-)
Cya
-- Benjamin Dulau - anonymation CEO anonymation.com | code.anonymation.com ben...@anonymation.com
Another question which we haven't really talked about when do we use a
protected property, and when do we use a private property but add
getters? In PHP, the latter is generally slower than allowing direct
access to the property, but giving direct access to the property will
effectively make the property mutable as we have no way to declare it
final or otherwise immutable.
How should we handle these cases? Generally, add setters/getters and
if performance is impacted make the property protected but clearly say
that we do not guarantee BC for the property, but that users should
use the setters/getters instead?
Kind regards,
Johannes
On 11 Mrz., 09:56, dbenjamin <bd.web...@gmail.com> wrote:
> +1 for privates.
> +1 for good usage of the final keyword as it can be a great tool to preserve
> code consistency and to control "what" the developer can override.
> A great example is for final constructors which call explicitly a
> initialize() method to allow developer to do "extra" stuff.
> +1 because it's a pain in the ass when you start a huge project with a
> version of a framework and when at some point you want to update your
> vendors with the last releases to benefit of all the new stuff and bugfix
> and improvements and all. How many of us just said one day : "Hum it's
> working well as it is, why touching anything ? Just let it on this 2 years
> ago release, as long as it works :)"
> "Design by contract" ! That's the Symfony 2 approach here, and that's what
> the end-user should do ! The DIC is a great tool. That's the best approach
> for the developer on so many points and particulary to have total control of
> its code, instead of overriding all he sees. (Take Magento for instance,
> it's a nightmare).
> I just want to be able to update my vendors at any time, and don't want to
> be stressed about it. I just want to read the change log and say "Yeah cool
> stuff. Hum, nice the bug is finally fixed !", and then play around with
> my Care Bears friends :-)
> Cya
> --
> Benjamin Dulau - anonymation CEO
> anonymation.com | code.anonymation.com
> ben...@anonymation.com
For the most part, isn't it safe to assume that for each property,
there will likely be an appropriate getter/setter?
Classes where properties are internally tracking state, caches, etc.,
may not have a public accessor method for such granular, internal
data, but that would be one of those situations where opening up the
API for extension purposes may make sense.
Great discussion, btw.
On Mar 10, 1:34 pm, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
> > Yes, interesting discussion.
> > What I understood is that symfony2 is such a sophisticated framework
> > that every possible use case is already taken care of, and because of
> > that everything should be private/final. If you are sure that's the case...
> no we are not sure that this is the case. so we will review requests to open the API on a case by case basis. we are just reversing from defaulting to protected to defaulting to private.
> > Why not just put a sentence in the documentation: "protected
> > properties/methos are not part of the API and can be changed any time"?
> because that would also not be correct, since we do have places where we invite users to inherit and reuse methods.
> regards,
> Lukas Kahwe Smith
> m...@pooteeweet.org
On 10 Mrz., 20:34, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
> > Why not just put a sentence in the documentation: "protected
> > properties/methos are not part of the API and can be changed any time"?
> because that would also not be correct, since we do have places where we invite users to inherit and reuse methods.
that's right. What about public methods which are not really meant to
be part of the public API (but need to be public for internal
framework use) – do you have a specific way to warn developers that
they shouldn't use them?
If a method is public, it can be used from outside, not matter how internal the class is. If its an internal class, and its critical an you don't want users to abuse that method, declare it final. The change is not about preventing developers from using some methods, go for it, you can use any public method. It is about closing points of unexpected inheritance, and leaving places for developers to extend the framework by providing alternative implementations.
As I replied to someone on twitter its best to refactor code to inheritance instead of designing for it. In that sense Symfony2 is the only framework, where Controllers and Models and Views don't require any base class. This way we don't force any developer into our own inheritance trees, leaving most of their code re-usable and framework agnostic.
If you spot a case where you want to get ahold of a private property/method, please make your case and we will either tell you how to do it best using existing means, or open up the above-mentioned member to inheritance.
When framework developers only use protected methods and don't close classes for inheritance, it is not because they want the framework to be extensible to the very core. For the most part, it is because they are simply lazy to craft proper extension paths.
On Fri, Mar 11, 2011 at 3:21 AM, Robert Lemke <rob...@typo3.org> wrote: > Hi Lukas,
> On 10 Mrz., 20:34, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
> > > Why not just put a sentence in the documentation: "protected > > > properties/methos are not part of the API and can be changed any time"?
> > because that would also not be correct, since we do have places where we > invite users to inherit and reuse methods.
> that's right. What about public methods which are not really meant to > be part of the public API (but need to be public for internal > framework use) – do you have a specific way to warn developers that > they shouldn't use them?
> Would be perfect to have a common concept / convention for the bigger > PHP projects and if we find one, we'd gladly refactor our code to meet > it.
> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com
> You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en
I think the question is not so much "if" but more how we do it. Right now, I have changed most visibility from protected to private for the Security component. However, there are some cases where I'd like to keep protected properties for performance reasons instead of declaring something as private plus adding a getter. However, that weakens the contract as all properties in PHP are mutable.
Also, you cannot generally say that all public methods are equal. In Java for example, constructs like this are possible:
class Foo { private class Bar { private $property;
public getProperty() { return $this->property; } }
}
We cannot enforce this in PHP via code, but we could add annotations like Robert suggests. The question is how far do we want to go, and do we want to have general guidelines when to use which strategy.
Kind regards, Johannes
On Fri, Mar 11, 2011 at 11:00 PM, Bulat Shakirzyanov <mallluh...@gmail.com>wrote:
> If a method is public, it can be used from outside, not matter how internal > the class is. > If its an internal class, and its critical an you don't want users to abuse > that method, declare it final. > The change is not about preventing developers from using some methods, go > for it, you can use any > public method. It is about closing points of unexpected inheritance, and > leaving places for developers > to extend the framework by providing alternative implementations.
> As I replied to someone on twitter its best to refactor code to inheritance > instead of designing for it. > In that sense Symfony2 is the only framework, where Controllers and Models > and Views don't require > any base class. This way we don't force any developer into our own > inheritance trees, leaving most > of their code re-usable and framework agnostic.
> Everzet also posted a fine comparison on twitter:
> If you spot a case where you want to get ahold of a private > property/method, please make your case > and we will either tell you how to do it best using existing means, or open > up the above-mentioned > member to inheritance.
> When framework developers only use protected methods and don't close > classes for inheritance, it > is not because they want the framework to be extensible to the very core. > For the most part, it is > because they are simply lazy to craft proper extension paths.
> Best,
> On Fri, Mar 11, 2011 at 3:21 AM, Robert Lemke <rob...@typo3.org> wrote:
>> Hi Lukas,
>> On 10 Mrz., 20:34, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
>> > > Why not just put a sentence in the documentation: "protected >> > > properties/methos are not part of the API and can be changed any >> time"?
>> > because that would also not be correct, since we do have places where we >> invite users to inherit and reuse methods.
>> that's right. What about public methods which are not really meant to >> be part of the public API (but need to be public for internal >> framework use) – do you have a specific way to warn developers that >> they shouldn't use them?
>> Would be perfect to have a common concept / convention for the bigger >> PHP projects and if we find one, we'd gladly refactor our code to meet >> it.
>> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com
>> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfony-devs@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-devs+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en
> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com
> You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en
> If you spot a case where you want to get ahold of a private > property/method, please make your case > and we will either tell you how to do it best using existing means, or > open up the above-mentioned > member to inheritance.
I have seen this argument a lot. Have you checked lately how many issues on the tracker of doctrine 1.2 for example have not even been read/commented by a developer in the last half year because all efforts go to doctrine 2.0? Today when everything is new, those changes will be done quickly. But later? And I do not expect a developer searching for a solution will want to wait for some months for a change, and be dependent on the good will of a developer. So this probably means that you have to use your own git clone then. And I am not sure how easy this is if you are using another SCS for your own projects. Generally I feel that a developer should be able to use the whole framework as he/she sees fit, and not like the framework developers expect it's best for him/her (which it certainly is in most cases, but not in all).
