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
<[email protected]>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:
>
> http://twitter.com/everzet/status/45632267107835904
> http://twitter.com/everzet/status/45630401347207168
>
> 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 <[email protected]> wrote:
>
>> Hi Lukas,
>>
>> On 10 Mrz., 20:34, Lukas Kahwe Smith <[email protected]> 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?
>>
>> (see http://robertlemke.de/blog/posts/2011/03/11/protected-vs-private
>> for our current approach in FLOW3)
>>
>> 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 [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/symfony-devs?hl=en
>>
>
>
>
> --
> *Bulat Shakirzyanov* | Software Alchemist
>
> *a: *about.me/avalanche123
> *e:* [email protected]
>
> --
> 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
