|
From: Jeremy F. <je...@go...> - 2005-03-28 17:42:42
|
Nicholas Nethercote wrote:
> The reason I did it this way is that with the ones I grouped together,
> the tool has to provide none of them or all of them. All tools have
> to provide pre_clo_init(), instrument() and fini(), so they're grouped
> together. If the tool wants to report errors (ie. needs_tool_errors),
> it has to provide all eight of those functions: eq_Error(),
> pp_Error(), etc.
> If it doesn't provide all of them the core will bomb out at some point
> with a "missing tool function" error.
>
> Does that make a difference to how you feel about it?
Well, a function with 15 (or even 8) arguments is always going to be
hard to read, and hard to write or modify (it's impossible to remember
what order they should go in, and very easy to stuff it up by adding or
deleting an argument - in either case you need to carefully check the
call against the function prototype).
Are you saying that the needs functions are, by definition, all-or-none,
so that if you want to add a new function with is related but not
essential (say, get_extra_address_info) would actually be a different
need? Or that a tool would be always required to implement a function
because of the all-or-none policy, even if its a nul implementation?
I'm all for grouping the interface callback registrations into
functionally related pieces, but it seems like a stretch to further
assert that functional grouping == all-or-none.
J
|