[Catalyst] Why does $c->stats require -Debug flag?

Jon Schutz jon+catalyst at youramigo.com
Sat Apr 19 15:48:00 BST 2008


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         




More information about the Catalyst mailing list