From: William S F. <ws...@fu...> - 2009-09-07 05:46:27
|
Jan Jezabek wrote: > William S Fulton wrote: >> Jan Jezabek wrote: >> >>> William S Fulton wrote: >>> >>>> Hi Jan >>>> >>>> I was just looking at your case-insensitive patches for COM. This >>>> approach stores the lowercase version of the symbol name in the >>>> symbol table. I was thinking a better approach would be to store the >>>> name without changing the case as by bastardising the original name >>>> it makes it user unfriendly, eg say we have a class MyAceStuff, all >>>> usage, documentation, messages regarding this symbol will now be >>>> myacestuff, which is a lot less readable or identifiable or >>>> recognisable in the code being wrapped. >>>> >>>> I suggest instead you leave sym:name as it is and modify the code >>>> where it gets added to the symbol table to make a case insensitive >>>> symbol name check so that symbols with the same name but different >>>> case then can't be added to the symbol table. You are likely then >>>> not to have to make the changes you had to in lang.cxx nor com.cxx. >>>> >>>> One minor and rather ironical point, is to please stick with the >>>> convention of all lowercase names for attribute names. So >>>> "sym:casePreservingName" should be "sym:casepreservingname" :) Short >>>> attribute names are best for performance, but if you go ahead with >>>> my proposed changes, you won't need this attribute name anymore, so >>>> that saves thinking about a good shorter name! >>>> >>>> William >>>> >>>> >>> Hi William, >>> >>> Thanks for looking at that :). You're most probably right; I >>> considered both approaches and thought at first that the approach >>> I've taken might be the better option, but after going through all >>> this 'lang.cxx' hell I don't think so anymore :] >>> >>> One problem that I have is how to organize the 'current' symbol >>> tables (and symbol tables in general) so that it uses case >>> insensitive matching. One obvious solution is to store the symbols >>> there in lower case, but this has one drawback that code like this >>> might not work: Getattr(current, Getattr(n, "sym:name")). I haven't >>> sen code like this, so I don't know if it's a big problem. >>> >>> Another option is to create a special type of a hash map, which >>> computes the hash based on a lower case version of the string and >>> performs case-insensitive comparison of the keys. If the target is >>> case insensitive, then this hash map would be used for the symtabs. I >>> think this might be the most elegant solution and unless you see some >>> major problems with it, I would like to go ahead and try it. >>> >>> >> >> I think the right way to handle this entirely in symbol.c when adding >> a symbol to the table. If the case insensitive symbol already exists >> then fail to add it. With regard to implementation, it is a bit >> trickier than it could be because the code uses Getattr() to see if >> the symbol already exists. I'd think about adding in a Getattrcase() >> to DOH which ignores case, like strcasecmp() does for strcmp(). >> Hopefully you only need to change a few Getattr() to Getattrcase() >> calls in symbol.c and that is it. >> >> William >> > Hi William, > > I have looked at the possibility of creating Getattrcase. There are a > few problems here: first of all there would also need to be a > Setattrcase, so that when an element is stored its case is not taken > into account when generating the hash. > But the bigger problem is that the DOH objects compute their hash values > themselves. Getattrcase and Setattrcase could take extra care if they > get a DOH String or C string as argument, but this would get destroyed > once resize is called on the hash map. For a moment I was thinking about > creating a new DOH type representing a case-insensitive, case-preserving > string (that is a string whose hashval and cmp operations do not take > case into account, but the case is preserved), but this might be overkill. > > Maybe something like this would be acceptable - the symtab would store a > lower case version of the symbol name, while sym:name would preserve the > case. This way the output would still be user-friendly (preserving the > original case). There would however be the inconsistency that I > mentioned earlier, that Getattr(current, Getattr(n, "sym:name")) would > not work. This should not be much of a problem however - the only > application of this idiom that I can think of is to find the symbol that > is being overloaded by the symbol at node n, but for this we have > "sym:overname". What do you think? > I think Olly's suggestion is probably going to be best, ie just have a duplicate symbol table storing the case insensitive names and just use that one for seeing if the case insensitive name already exists by calling Swig_string_lower on the symbol name before calling Getattr on the duplicate symbol table. William |