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