Matthew Astley ([EMAIL PROTECTED]) wrote:
> Piers Cawley ([EMAIL PROTECTED]) wrote:
> > Matthew Astley <[EMAIL PROTECTED]> writes:
> > > Piers Cawley ([EMAIL PROTECTED]) wrote:
> > > I was starting off down a "store the info in case anyone wants it"
> > > track. I assume it's a fairly fast call, but I've not measured
> > > anything.
I'd rather we didn't add stuff until it's actually needed.
> > > It occurred to me, perhaps we're at cross-purposes? My understanding
> > > of the plot has all debug calls going to some base class (this would
> > > be the listener?), and then pre-registered interested parties (GUI,
> > > suite set-up script) can get called do something with the info that's
> > > useful.
> > >
> > > If nobody's registered, you shortcircuit the call...?
If noone's registered, I should imagine that would result in iterating
over an empty array, so no need for any extra short-circuiting.
> > > > Eww... If you're going to keep state like that, keep it per run and
> > > > stick it in the Listener methinks.
> > >
> > > Well it hasn't even got that far AFAICR. Did we ever find some
> > > concrete examples of "state" we wanted to keep?
> > >
> > > - backtrace quelledness
> > > - (some) debug handlers
> > >
> > > are the only ones that spring to mind just now.
Don't forget my idea (patch soon) of having filter tokens, so that you
can control which test methods get run by tokens. The tokens would
certainly need to be state in the listener.
> > As a matter of interest, have you *ever* seen a useful backtrace from
> > assert?
>
> No.
Nor me.
> I'm assuming that somebody uses them though, since somebody bothered
> to add the code. <shrug>
Looks like Christian did, according to cvs annotate, but he's away at
the moment I think.
> I'm inclined to just leave it in as dead code in the __DATA__ section,
> unless anyone thinks that's untidy?
I vote just get rid of it. We can always retrieve it - that's what
CVS is for ...
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
