Handlers filenames and syntax versions (bug 681)
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Wed Oct 22 07:27:30 PDT 2003
Neven Has wrote:
> Well, handler_data enum would still have to be in handlers.h (or
> nALFS.h), so we can't completely keep that information in handlers
> themselves anyway. So the only reason I see for having it in a new
> handler_info member too, is for the main code to check (at run-time)
> if it can be really provided, as you say? But I'm probably
> misunderstanding you completely... How would the main code use that
Right, my thought was that instead of the main code "knowing" that a
particular handler creates a command to execute, it would instead
check a flag variable in the handler_info structure to _learn_ that
the handler creates a command to execute, and then the main code could
act accordingly. Another way of doing it would be to stick with the
code you already posted, but make sure that the handler's alloc_data
function always returns NULL for data elements it can't provide; the
main code could then just call alloc_data every time through, and only
act if it gets non-NULL back.
Really, what was making me think of this was things like the "package
name/version" information; very few handlers can provide that (only
<package> at this point), so it seemed to make sense for that specific
handler to be able to tell the main code that it can provide that
information. Think of it like OO programming, where the <package>
handler would implement an IPackageHandler interface, and the main
code then knows what extra functions it can call. In this case, it
would just result in some extra calls to alloc_data to get the
relevant information. Does that make any more sense to you?
> Interesting. I'll add it as well, I agree it can be useful.
> But I don't think we should keep those as flags in a single
> variable. They don't have anything in common, except they're both
> bools, so I don't see a reason for that (don't say memory saving ;).
> Plus, the "custom" flag you suggest can even be a "priority" value?
Yes, it could be a priority value, I had considered that as well but I
don't know how often anyone would actually use it. However, since it's
not hard to implement, go for it. And I agree, even though they are
all bools, having them be separate char variables is fine, we're not
using that much memory :-)
> Not much in this case (handler_info_s). But in general, it's a good
> old maintainability and readability (handler_function_f) that I like
> about them. Although I should lose the ugly _s, _e, etc. suffixes,
> when speaking about maintainability. Not sure why I started to use
> those, I guess I _did_ miss struct, enum etc. keywords. ;)
Once you take the suffix off of the typedef, then it makes more sense
to go back to using "struct handler_info" instead, for that very
reason. Don't be upset if I do that when I clean up code and have to
create new strucures, it's the habit I'm in :-)
> Actually, it will be possible to have different handlers (for
> different elements) in the same file. Entire syntaxes could be
> implemented that way for example, putting all handlers (with different
> names) in one file.
> So maybe it would be better to leave it this way, to make that clear?
Yes, that is a good point, and something I hadn't considered about the
new handler structure. That's cool, somebody like the LSB could have a
single source file that provides all their custom handlers.
> Good idea. BTW, what do you think about putting all those local
> #includes that handlers still use into nALFS.h? Of course, just
> temporarily, to clear up the mess.
I think it would be better to merge them one at a time, copying over
just the relevant bits and keeping the private bits in the existing
headers. I was going to make that my next project after the
handler_info conversion, and will still do that once you have finished
the conversion (otherwise we'd be fighting each other in the CVS
More information about the alfs-discuss