From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6567 invoked from network); 31 Dec 1996 12:22:35 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 31 Dec 1996 12:22:35 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id HAA05904; Tue, 31 Dec 1996 07:26:38 -0500 (EST) Resent-Date: Tue, 31 Dec 1996 07:26:38 -0500 (EST) From: Zefram Message-Id: <28714.199612311227@stone.dcs.warwick.ac.uk> Subject: Re: Option reorganisation, Part IV. To: hzoli@cs.elte.hu (Zoltan Hidvegi) Date: Tue, 31 Dec 1996 12:27:44 +0000 (GMT) Cc: zefram@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu In-Reply-To: <199612301553.QAA06135@bolyai.cs.elte.hu> from "Zoltan Hidvegi" at Dec 30, 96 04:53:49 pm X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8657.59 X-US-Congress: Moronic fuckers Content-Type: text Resent-Message-ID: <"v1qTA2.0.8S1.zPGoo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2684 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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