On Fri, 2008-04-18 at 19:54 +0100, Matt S Trout wrote: > On Sat, Apr 12, 2008 at 08:37:49PM +0930, Jon Schutz wrote: > > Prior to 5.7012, $c->stats was an internal object (in so far as it was > > not documented as part of the API) so anyone manipulating it directly > > does so at their own risk. > > This one user who was kind enough to report it to the list will by far not > be the only one with this problem. > > Catalyst::Plugin::SubRequest was also hit by this. > > Never, ever assume that 'undocumented' means 'I can break compat any time > I like'. This works in theory, and in theory, theory is the same as practice, > but ...
I apologise to anyone who was inconvenienced by this change. I've written a guide to upgrading for anyone who was using the Tree::Simple object directly: http://notes.jschutz.net/17/perl/adding-action-timings-to-your-catalyst-output Nevertheless I stand by my comment that anyone who digs through the source code to find an internal object or function and then chooses to use that in external code does so at their own risk. Furthermore I suggest that anyone who is savvy enough to get into the code, understand it, and chooses to use an internal object/function, is aware of the risk and is more than capable of adapting their own code should an internal object/function change. > > > Catalyst::Stats was introduced to define an > > interface for the stats object so that one could safely override the > > default implementation if they wished; the default implementation also > > introduced profiling methods that were not there before. > > You need to consider your failure to maintain backwards compatibility a bug > and fix it. I said this at the time but apparently you didn't get round to > fixing the Catalyst::Stats patch. Please do so as soon as you get time; > Catalyst::Stats' API is a great leap forward but not at the cost of > previously running code (although I think perhaps the compat code -should- > warn that you're using an API you shouldn't have been and that it'll go > away in the future). How would one define backwards compatibility in this case? That $c- >stats must return a Tree::Simple object with all of the same user- defined fields as before? The logical extension of this argument says that on any minor release, the internal representation of *any* stored data or the signature of *any* internal function or method may not change, which surely is too restrictive on developers. 5.7012 has been out since December 2007. It seems to me a case of closing the gate after the horse has bolted. I don't hear an angry mob out there complaining. Perhaps as a result of this being raised the angry mob will come knocking; that being the case, I'll be happy to revisit the code. As it stands I'm unconvinced of the need for backward compatibility in this case, both of the principle (of preserving unpublished undocumented undefined interfaces) and the level of popular demand. -- Jon Schutz My tech notes http://notes.jschutz.net Chief Technology Officer http://www.youramigo.com YourAmigo _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
