develooper Front page | perl.perl5.porters | Postings from November 2000

Re: Plan to try again with Carp

Thread Previous | Thread Next
Ben Tilly
November 27, 2000 04:28
Re: Plan to try again with Carp
Message ID:
Wolfgang Laun wrote:
>Ben Tilly wrote:
> > As I mentioned a long time ago, Carp's internal semantics
> > make little sense.  There is also the possibility for
> > endless loops if you have circular inheritance as this
> > shows:
> >
> > package A;
> > @ISA = ("A");
> > use Carp;
> > sub complain {
> >     carp(shift);
> > }
> > package B;
> > A::complain("Hello world\n");
>And so does
>   package A;
>   @ISA = ("A");
>   sub new { bless {}, shift }
>   sub complain { shift->SUPER::complain; }
>   package B;
>   A->new->complain;
>but this is not meant to imply that this should not be fixed in

Heh. :-)

> > So to summarize I would like to kill the undocumented
> > $Carp::CarpLevel.
>I think that $Carp::CarpLevel should be documented and not omitted.
>Error reporting functions at some static calling level away from Carp
>can make good use of it.

The current shortmess behaviour with regards to it makes
no sense at all.  Being restricted by it internally to
Carp also makes little sense.  To me the %Internal and
%Ignore behaviour makes a lot of sense, and I see no easy
way to reconcile what they do with $CarpLevel.

For long messages I actually can see a point to it.  For
short ones, well I have not figured out any reasonable
behaviour consistent with its use for long messages.

> >    redo if $Internal{$pkg};
> >    redo if $Ignore{$pkg};
>How would these hashes be set up and/or maintained? (Comments in Carp
>express strong sentiments so as not to cause delays during program load
>& initialization time.)
In you would add
$Internal{Carp} = 1;

In you would add
$Carp::Internal{warnings} = 1;

In you would add
$Carp::Ignore{Exporter} = 1;

The real effect of the third command would only be to edit
Exporter out of messages if someone set $Carp::Verbose to
true.  The heuristic that shortmess_heavy uses already
edits it out of any carp() and croak() calls that Exporter

The initialization and loading penalty should be
negligable, and realistically only a few modules
in the core would have any need for it.
> >    redo if trusts($called, $caller, $cache);
> >    redo if trusts($caller, $called, $cache);
> >
> > Where right now trusts would be basically "inherits from"
> > though we could change that later.
>I'm currently exploring and implementing the idea of adding Carp::layer,
>whereby some package can add itself to the "trusted" group of another
>package but I'll hold back if some rewrite is in the offing.
If my proposed semantics are not too controversial, I will
have my proposal out in a few days.  After that we can
define trust semantics.  Personally I think that the idea
of starting with @ISA is appropriate enough to use as a
heuristic, but may need tweaking.  However having the code
already structured in terms of A "trusts" B will make
any proposed mechanism for tweaking much easier to implement.


PS Something that I am wondering at.  I often personally use
"confess" when "croak" should do because I find it useful
to get the arguments to the current function call.  Would it
be a bad idea to have the short message have added the
current arguments?  That would have saved me a lot of
headaches in the past.
Get more from the Web.  FREE MSN Explorer download :

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About