brian moseley <[EMAIL PROTECTED]> writes:
> On Thu, 22 Nov 2001, Stephen Adkins wrote:
> - component: this seems like the beginning of an object
> base class. i wouldn't mind seeing such a thing, as it could
> provide standard object utility and lifecycle methods (new,
> init, start, stop, recycle, destroy/DESTROY, equals and
> to_string spring to mind) that p5ee apis could count on.
Definitely having some common methods becoming available would be
great. Back when I was toying with writing YA generic persistence
layer I kept butting up against the fact that there's no (reliable)
way for finding out what fields an object has. And it'd be *really*
nice if I had some mechanism for 'dirtying' objects so I'd know
whether they need writing back to to the database, but that's overkill
I think. But that might be better addressed by using a
Class::MethodMaker like approach.
> - debugging: this one is hard, and i still haven't figured
> out a really great general purpose way to handle it. ideally
> the amount of debugging/trace output should be able to be
> specified differently for each api or component.
> furthermore, debugging should be removable/compilable
> out/whatever for production mode.
Take a look at Aspect::Trace which has some very neat tricks for
adding logging to 'random' methods. Using Aspect it is, in theory
possible to write an advice set that logs the passage of a single
object through a system...
> finally, there should be some way of outputting human readable
> representations of object attributes - maybe we just count on a
> to_string method existing for each object in each api, or maybe our
> debugging api includes a dump_object method.
If we go with having either a common base class or a standard class
factory we could mandate something like:
$object->inspect_with($inspector);
which calls
$inspector->inspect($inspectable_meta_object)
And it would then be up to the inspector to work out how to display
this.
Note that having this sort of 'inspect' method would be useful for
rather more than just debugging. For instance, a persistence engine
could make use of it to work out an appropriate database schema...
By mandating an 'inspectable_meta_object' you get to 'decorate' it
with meta data about the various fields. Also, in the case where a
field contains another inspectable object, its inspectable_meta_object
(or a proxy to avoid infinite recurision) can be hung off the
container's IMO and so on.
>
> - exceptions: i heartily agree with using Exception::Class
> for exceptions, altho i submit the following suggestions:
>
> 1) it should be possible to decide whether or not the
> stack trace will be generated at the time the exception is
> created/thrown
>
> 2) we should create a standard hierarchy of common
> exceptions - IOException, IllegalArgumentException,
> IllegalStateException, IndexOutOfBoundsException,
> UndefReferenceException (hee), LifecycleException, etc. most
> of these are probably useful outside p5ee as well.
Some of these are going to be tricky to implement though. We're going
to end up with a horrible big 'ExceptionFactory' being called from
'die' aren't we? I want to see this, I just don't want to be the one
who gets stuck with implementing it. Code generation from perldiag
ahoy...
> 3) all apis guarantee that to the best of their ability,
> only exception objects are thrown, so that consumers of the
> apis don't have to defensively code with "if ($@ && ref $@
> && $@->isa('Exception::Class::Base'))" or whatever.
Oh yes. This is one of the nicer things about Error.pm's
try...catch... syntax. Shame about the memory leaks really.
>
> - logging: all higher level apis need to take logging into
> exception. they absolutely should not use warn, and they
> should allow api consumers to specify a log channel to which
> the api internals direct all log msgs. furthermore, the
> logging api should allow apis to log at various severity
> levels and to register some kind of identity with the logger
> so that log messages can be matched to specific api
> components.
If we have a common base class that's a lot easier of course, you can
do $self->log_warning(...), $self->log_error(...), etc.
The answer to the 'speed' issue is going to be 'buy a faster computer'
isn't it?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
