> 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...
Obviously we disagree. The use case you mention is hypothetical. I could make a hypothetical use case for any non-public property. Reality is that the real solution to the only existing known problem was to change the constructor, and protected or private (not advocating private in this case) reduce that API maintenance burden, so it has some value. Anyway, I'm not trying to make a big deal out of this. This is how commit wars start. 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 -~----------~----~----~----~------~----~------~--~---
