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

[Matt S Trout]

On Sat, Apr 19, 2008 at 10:39:50AM -0500, Cory Watson wrote:
> On Sat, Apr 19, 2008 at 9:48 AM, Jon Schutz
> > 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.
> >
> 
> I'll assume you are talking about me, since I was the one who posted the use
> of the method.  I don't recall the circumstances, but I don't remember there
> being any particular red flags in the vicinity.  It was merely a method that
> returned a Tree::Simple object.  It's entirely possible I ignored any
> warnings. :)

It was used by C::P::SubRequest, which I'm betting is where you got the
idiom from.

Since that was released by somebody from the core team it effectively
legitimised the usage of the approach, even if it wasn't documented.

So no digging through the Catalyst source was required; Jon's very much
right in principle but we're stuck with a reality that doesn't work that
way.
 
> > 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.
> >
> 
> When we added the Statistics code to DBIx::Class we went to great pain to
> make the implementation behave exactly as it did before if the user didn't
> change anything.  It was a severe pain in the ass. :)
> 
> That being said, the internal code could've been changed beyond all
> recognition, so long as calling $c->stats() returned the same object as
> before.  This has nothing to do with the internal representation of the
> stats, only the way you choose to return it.

So far as I can see, all we really need to do is supply a proxy of the
common Tree::Simple method from the C::Stats object through to $self->{tree}
and we're done. That'll provide compatibility with obvious usages without
adding any significant compatibility overhead.

I was hoping Jon would do this because he was the original author of C::Stats
and could see any subtleties that needed paying attention to that I've
missed.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/