Good point. In which case, leave them like they are and forget the convenience methods (because they're not as convenient as they sound - a false economy).
Despite the long mail, I don't feel very strongly for either way, I just think it shouldn't be both. On 26 Apr 2011, at 18:40, Kris Wallsmith 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 -- 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
