Community
Participate
Working Groups
I looked into converting the Open Type dialog to use the new camel case matching support. While doing this I discovered the following problem: - we need the camel case matching routines for strings not for char[]. UI folks deal more with strings then char[] since all UI API take strings. Why do we need to do our own camel case matching: - we have to do the pattern matching for the history elements - we have to do the pattern matching for the cached result. To speed up the all type dialog it caches the last complete search query. When the next pattern entered is a prefix pattern of the last one the dialog queries the cached result instead of going to the search engine again. Always converting the strings back to char[] seems inefficient since the cached result can be large. Storing char[] in the UI is ineffiecient since we then have to convert them to show them in the user interface. This is even worse since it will double the memory.
Additionally I would like to see SearchPattern#verifyPatternMatchRule (or something comparable) become API since I have to find out for the cached result search what kind of match rule I have to apply.
Philippe agreed on the fact we implement this helper in JDT/Core. Note however that performance will not be the same than those using corresponding CharOperation method. What about to add static method camelCaseMatch(String,String) on SearchPattern?
(In reply to comment #1) > Additionally I would like to see SearchPattern#verifyPatternMatchRule (or > something comparable) become API since I have to find out for the cached result > search what kind of match rule I have to apply. I don't think you really need to store optimized match rule, just one entered by user. SearchPattern will optimize it again when user will select a previous search in the list, extra time for optimization is definitely negligeable...
Having the methods on SearchPattern sounds fine for me. Regarding verifyPatternMatchRule: I think my explanation was misleading. So here is my problem: - user types in NP and search engine correctly interprets the pattern as a camel case pattern - the dialog caches the result - the user adds a * to the pattern NP* - for performance resons we are now narrowing down the cached result. Since we have to do our own matching in this case I need to find out what kind of pattern NP* is to call the right methods on Core & JFace. From my understanding verifyPatternMatchRule is exactly doing this. It will tell me that the pattern is a wildcard pattern and not a camel case pattern anymore.
I've released in JDT/Core HEAD stream 3 new API methods on SearchPattern to match your requirements: public boolean isCamelCase(String,String) public boolean isCamelCase(String,int,int,String,int,int) public int validatePatternMatchRule(String,String)
Verified for 3.2 M3 using build I20051031-0010 but the real names of the methods are: public boolean camelCaseMatch(String,String) public boolean camelCaseMatch(String,int,int,String,int,int) public int validateMatchRule(String,String)
