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
> info?

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 
repository).




More information about the alfs-discuss mailing list