Proposal for Abstraction Layer for Modifications in Bug.pm
Maxwell Kanat-Alexander
mkanat at kerio.com
Tue Jul 6 21:52:29 UTC 2004
> That's true, but I guess one cannot expect an API to completely catch all
> programming errors. I don't know whether this potential error is worth the
> overhead described below.
>
> It's always a trade-off...
Yes. However, an API should *never* expect a programmer to read it. An
API should also never expect a programmer to run disrelated functions in
a specified order without enforcing that order.
In general, the rule of thumb is: It is never OK for one programmer to
demand something of another programmer without enforcing it in code.
> IIRC, 3 will only be called for completely new errors as all required field
> should be filled with appropriate values.
> Therefore, calling 3 everytime when committing will result in quite a few
> unneeded calls.
>
> Not that calling 3 in 4 is a problem, but IMHO it's better to do this
> seperately.
OK. Then you can write a function called check_default_fields that
quickly makes sure that all the default fields are filled in. I think it
will add very little overhead, if commits are being batched anyway.
Or, you could have a little flag called "defaults_filled," and check
that quickly. That would be pretty simple, and would add even less
overhead.
-Max
--
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.
2041 Mission College Blvd. Suite 100
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
Web: http://www.kerio.com/support.html
More information about the developers
mailing list