You were present during the IRC conversation that presented one. If you don't see the use case there's nothing I can do to help that...
The fact that you can pass in the $escape parameter to a method that does a large loop, but can't set it yourself to avoid re-creating that loop in your own code is asinine to me. As with virtually everything else, the presence of choice is a good thing. When in doubt, let the developer decide. As I told Owen on IRC this afternoon when we were establishing this list of revisions, it would potentially fix a problem mikelietz had had with a plugin. Just because he was able to change the constructor in his specific instance doesn't mean everyone else is able to or should have to. It's not a significant change and could solve a problem, so it should be considered a bug fix. Whether you agree with the API or not is beside the point... On Sat, Apr 18, 2009 at 4:03 PM, Sean Coates <[email protected]> wrote: > > > Looking at it briefly, if one assumes that it is a reasonable > > expectation to be able to set the $escape value after the object is > > created, then you have either the choice of making $escape public or > > providing an accessor. Writing an accessor now would be trivial. Can > > we do that, or is your objection more that there should be no > > expectation to change the value of $escape? > > I just couldn't think of a use case where escaping behaviour would > need to be changed after object creation. > > S > > > > > --~--~---------~--~----~------------~-------~--~----~ 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/habari-dev -~----------~----~----~----~------~----~------~--~---
