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

[Jon Schutz]

On Sat, 2008-04-19 at 10:39 -0500, Cory Watson wrote:
> On Sat, Apr 19, 2008 at 9:48 AM, Jon Schutz <jon
> +catalyst at youramigo.com> wrote:
>         
>         
>         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
> 
> 
> I've updated my post to point to yours, so that people see the correct
> way to do things.
>  

Thanks!

>         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. :)

I was speaking generally; it's about the principle (in theory and
practice) rather than the specifics of what went on here.

>  
>         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.
> 

That's true, but the motivation to do so comes from accepting $c->stats
as a legitimate interface.

> 
>         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.
> 
> 
> It broke my code also.  I just fixed it and went back to work. :)
> 

Thanks for your pragmatism.

> 
> I agree with your assertion that the horse has already bolted, but I
> think you are missing the point of Matt's comments.  Maintaining
> compatibility in these situations is a PITA, but it's what separates
> the good projects from the bad ones.

I'm making a stand here for the rights of all developers!  Backward
compatibility is a must for defined interfaces, but to carry that
through to say that all design decisions turn into interfaces that must
be preserved, even though not meant for external consumption,
discourages innovation.  Many factors separate good projects from bad,
and one is well defined interfaces!


-- 
Jon Schutz                        My tech notes http://notes.jschutz.net
Chief Technology Officer                        http://www.youramigo.com
YourAmigo