RE: A common base exception object for Perl - RFC

["Redford, John" <John.Redford@fmr.com>]

You're saying that
	var =~ s/a/b/;
should be morally equivalent to
	var = regexp_string_replace(var, /a/, 'b');
for all variables except $@, because it might surprise people if it behaved
consistently?

		-----Original Message-----
		From:	Larry Wall [mailto:larry@wall.org]
		Sent:	Friday, January 21, 2000 1:38 AM
		To:	gibreel@pobox.com
		Cc:	Pete Jordan; Perl5 Porters
		Subject:	Re: A common base exception object for Perl
- RFC

		Stephen Zander writes:
		: >>>>> "Pete" == Pete Jordan <pjordan1@email.mot.com>
writes:
		:     Pete> Fair point. OK, you've convinced me. I can
derive a
		:     Pete> structure from Graham's C<Error> module - a bare
framework
		:     Pete> base class and C<Exception::Simple> which would
implement
		:     Pete> what I originally described.
		: 
		: As someone who bitched loud & long about this at the last
conference I
		: have one question: do you plan to fix all the croak calls
in the
		: current source code and/or supply some mechanism for XS
programmers to
		: Do The Right Thing as well?  The whole point of having
*any* exception
		: class is wasted if it only applies to custome code and as
along as you
		: support the auto-stringification (is that a word?) of $@,
the Backward
		: Compatability Police can't touch you.
		: 
		: BTW, as backwards compatability requires you to support
		: auto-stringification of $@ anyway, why bother with a
'to_string'
		: string method at all?  This:
		: 
		:         print $@;
		: 
		: is so much less typing than this:
		: 
		:         print $@->to_string;

		That's the plan.  In fact, it may be that stringification
and
		numification methods ought to be supported even in the
absence of
		ordinary operator overloading.  I could have used that in
the
		Java/Perl thingie I did a couple of years ago.  Not that
stringify
		overloading didn't work fine for that, but I felt strange
making
		all those classes with only '""' overloaded.  Made me think
something
		isn't decomposed quite right.

		Another interesting question is whether $@ gets denatured or
stays an
		object when you do

		    $@ =~ s/foo/bar/;

		It could be made to stay an object, if $@->STRINGIFY returns
an
		lvalue.  That probably makes more sense than denaturing $@,
since other
		code may rely on $@ remaining an object.

		Larry

---

Follow-Ups from:

Larry Wall <larry@wall.org>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---