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

[Cory Watson]

On Sat, Apr 19, 2008 at 9:48 AM, Jon Schutz
<jon+catalyst at youramigo.com<jon%2Bcatalyst 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-o=
utput
>

I've updated my post to point to yours, so that people see the correct way
to do things.


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


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

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

-- =

Cory 'G' Watson
http://www.onemogin.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080419/549c0=
74e/attachment.htm