Re: Option reorganisation, Part IV.

[Zefram <zefram@xxxxxxxxxxxxxxxxx>]

Zoltan Hidvegi wrote:
>Yes it is faster but not much faster and it is quite rarely needed.  I do
>not see why should we use hashtables if we do not use scanhashtable.  If
>you want to use the array you might as well stay with the old system adding
>binary search to optlookup to make it faster.

The point of a hashtable is to make name lookups very quick.
scanhashtable() is used when it is necessary to look at all elements in
a hash table; in this case it is not necessary, as there is another,
easier, way to look at all the options.  And, of course, going through
the hash table elements means that alias entries will also be
encountered, and must be ignored, whereas going through the option
table avoids this.

>Hashtable functions has the advantage that the order of the options does
>not matter.  If we add all new options to the end of the enum list we do
>not have to recompile everything and we can keep optns list alpabetically
>ordered.

That already applies.  The reason we have to recompile is that we keep
the enum in alphabetical order too.  Anyway, we don't add options very
often.

>I did not want to move zle options to the zle module.  But one might
>implement a new module which requires some new options.

There are other mechanisms than these options.

>I did not think about autoloaded options but even if an option is
>autoloaded it can be set without the module where it is used.

Then autoloading an option is equivalen to letting the user create new
options on the fly.  I really don't think we want to do that.

>Yes but againg you do not win much here.  I could store numbers for aliases
>but that without optno -> name reverse lookup I'll not be able to print
>these aliases.

I don't see what you mean here.  The option aliases should never be
output; they're just extra names that can be used when specifying
options.  All that is needed of an option alias is a mapping from name
to number, and putting the number directly in the hash table element
achieves this with the minimum of fuss.  There is simply no need to map
from alias name to canonical name.

>One more argument: builtins has been stored in a static array before
>modules appeared and noone wanted to use array functions on them.  But I
>know it is a bad example.

The difference here is that options *are* internally identified by
number, not name.  The system I produced had options operated on by
number internally, with simple table lookups to get the option flags
and canonical name, and used the hashtable only to map user-specified
names to numbers.  Your system uses names internally in some places,
and numbers in other places.

>> the way you handle the structures with the union is not strictly
>> conforming, and quite likely to break on 64-bit machines using the LP64
>> model.)  I don't see the point in doing this.
>
>The struct iparam in hashtable.h is even worse.

That's no excuse!  :-)

The code can be made more portable by having two structures, one being
the normal structure with the union, and the other the same but with
the union members the other way round.  It is possible to initialise
the first member of a union, so by using these two structures you get
the ability to initialise either member of the union.  An
implementation would have to be actively perverse for this to fail.

-zefram