[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]
RE: A common base exception object for Perl - RFC
With a minimal base class you gain two things. First, all exception objects
can be subclasses of Exception, permitting:
$@->isa('Exception')
as a common handler for any exception. Secondly, the author of an Exception
subclass does not have to ever know about the '""' code. While simple
looking, it would be a large distraction for people to have to read `perldoc
overload` (or think they have to read it).
Certainly when Tom is around, 'to_string' is better than 'toString'.
You're right, it would be likely just as well if Exception implemented
$@->to_string === sub { "Base Exception" };
Exception, or some other module, may want to export a function to
conveniently hide the complexity of:
ref $@ and ref $@ !~ /^(HASH|ARRAY|GLOB|CODE|SCALAR)$/
to permit:
if ( blessed $@ and $@->isa(...) ) { ... }
P.S. (sorta)
While I'm near the topic again, I'd like to comment that it would be
nice if people ceased to talk about looking in @ISA for information about
objects. Using a non-OO technique to handle objects is very limiting. Just
use the 'isa' method, and leave the details of implementation out of it. Not
all objects have an @ISA.
-----Original Message-----
From: Martyn Pearce [mailto:m.pearce@inpharmatica.co.uk]
Sent: Thursday, January 20, 2000 10:35 AM
To: Redford, John
Cc: 'Pete Jordan'; Perl5 Porters
Subject: RE: A common base exception object for Perl - RFC
Redford, John writes:
| 1. Make the base class minimal. Do not include any special fields like
| 'name', 'errcode', or 'exitcode'. Don't include any fields or methods,
just
| the '""' override.
Am I being obtuse (probably...), or does this gain us nothing?
Arbitrary items aleady get stringified --- to HASH(0xffff) or some
such. With point 3 below, you're just stating a standard method name
for "". I don't see how this helps us.
| 2. 'toString' instead of 'render'.
As we're on naming, to_string would be more consistent with other perl
modules.
| 3. Base implementation of '""' as follows:
| sub { $_[0]->can('toString') ? $_[0]->toString() : "" };
| Just enough to avoid errors with existing code, without requiring a
| conversion function to exist.
Supplying a simple to_string, e.g.,
sub to_string { "override me!" } would suffice hear. Why check for the
existence of a method you might as well implement (you could of course
use your "" if you felt it better...)
Also, Pete:
> PROPOSED INTERFACE
>
> use Exception qw(-stacktrace);
>
> my $e=new Exception 'text';
>
> my $f=new Exception -text=>'foo', -class=>'Error',
> -name=>'bar', -errcode=>$!, -exitcode=>23;
>
the use of -foo for configuration items seems to me to be something
picked up from Tk and/or analogy with command-line calls. I'm not
convinced that they help here; and I don't see them used commonly
through the non-Tk modules.
| The Exception object model should not preclude the use of "better" Perl
| objects which are not based on HASH refs (or pseudohashes). If common
| practice is to treat $@ as "A string or a HASH ref", it becomes impossible
| (again!) to use arbitrary reference types in $@.
Part of the very purpose of OO implementations is to encapsulate
data-structure --- the client certainly should not be utilizing the
HASHness of a particular impl.; everything should be called via methods.
Mx.
- Follow-Ups from:
-
Pete Jordan <pjordan1@email.mot.com>
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]