I'd vote in favor of keeping the public properties. Request and response in Symfony2 (or HttpKernel at least) seem analogous to Doctrine's ClassMetadata, which keeps public properties for data that is accessed very frequently during the application.
I think the Request and Response classes in their current state are quite elegant, so don't see a need for convenience methods. I will say I haven't used Response to set cookies or headers, so I can't comment about their related confusion. On Tue, Apr 26, 2011 at 1:40 PM, Kris Wallsmith <[email protected]>wrote: > I’m in favor of leaving these public properties as is and not adding any > “convenience” methods. I think it’s easier to remember the very simple > ParameterBag API and the names of a few public properties than to remember > when there is a convenience method and when I have to ask for the parameter > bag and work with that directly. The current code is a very elegant > solution; let’s not mess with it at the last minute. > > Thanks, > Kris > > On Tuesday, April 26, 2011 at 10:36 AM, Matt Robinson wrote: > > On 26 Apr 2011, at 16:54, Lukas Kahwe Smith wrote: > > On 26.04.2011, at 11:19, Johannes Schmitt wrote: > > +1 for adding convenience methods where it makes sense > -1 for removing public properties > > > I agree. > > > +1 for get/set methods. The examples were a lot tidier and more readable. > > Why not remove the public properties? If you introduce get/set methods and > leave the properties public, what's the message behind that? (Bear in mind > these are wild exaggerations, please don't be offended, I don't think anyone > is thinking this, it's just easier to get the point across if I make it a > bit too strongly) > > 1. You might be suggesting that there's a right way to do it (properties), > but there are "convenience" methods if you're lazy or a stupid beginner > (boy, I'm looking forward to thinking I'm not coding properly because I like > simple, expressive method names ;). > > 2. Or maybe you're saying that you realise that get/set methods are the > right way, but you're leaving properties public to save early adopters some > effort. Then you're effectively launching Symfony2 with deprecated > properties, which isn't a great way to start. > > 3. Or perhaps you have two ways because it's not a big deal, it's such a > minor issue, so allow both. But if you do that for every little thing, the > framework ends up confused, with so many different ways to do the same thing > that no one knows the right way to do it, and they have to learn all the > wrong ways as well as the right one so that they can understand other > people's code. > > So I think you should pick one method (properties or methods) and remove > the other one. To paraphrase the Zen of Python: > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're French. > > Maybe we should have a Zen of Symfony to guide us in these trivial matters? > :) > > -- Matt > > -- > 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 > -- jeremy mikola -- 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
