In Doctrine we mark public functions that are meant for internal use only in the doc block:
https://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/UnitOfWork.php#L1191 - Jon On Fri, Mar 11, 2011 at 7:05 PM, Johannes Schmitt <[email protected]>wrote: > 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 > -- Connect with me on *http://twitter.com/jwage* <http://twitter.com/jwage> and http://about.me/jwage to keep in touch. -- 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
