[Scummvm-devel] Case agnostic handling for directories (and files)

[Johannes Schickel]

Max Horn wrote:
> Am 22.09.2009 um 12:39 schrieb Johannes Schickel:
>
>   
>> Max Horn wrote:
>>     
>>> A better way would be to loop over all children of _gameDataDir,   
>>> compare the name of each to "execute", *ignoring case*. And add  
>>> every  match.
>>>
>>> It's pretty easy to implement that, the main question(s) involve   
>>> details, I feel:
>>> * new  method of class Engine:
>>>     void Engine::addGameDataSubdirToSeachMan(String caselessName);
>>>    OR
>>>     void Engine::addGameDataSubdirsToSeachMan(String pattern, bool   
>>> ignoreCase);
>>>
>>>       
>> Do we really need these?
>>     
>
> Not necessarily. My email was a bit garbled (happens if you copy&paste  
> too much :-/ ). Think of it as saying the following, right after  
> "involve details":
>    "Potential ways to address this include the following new APIs (we  
> could take one or both or none :)."
>   

OK :-). Actually without those and the SearchMan calls, we might give 
the engine developers another chance to get familiar with the new API, 
which could also be used instead of the old Common::File ;-).

>> Looks fine to me. Actually I had something very similar in mind ;-).  
>> Short question though: is there any use case for the pattern match?  
>> It shouldn't be much overhead to implement it (especially since one  
>> could easily implement the method just taking the caselessName via  
>> the pattern one), but actually I fail to see where it is really  
>> useful.
>>     
>
> I have no particular example in mind. It was just natural given the  
> name "addSubdirsMatching" ;), and given the fact that it's a trivial  
> one line addition to turn the former into the latter. Also, I feel  
> that this name is not so suitable if we go with the "single caseless  
> string" variant... OTOH the function name should still indicate that  
> multiple dirs might be added.
>
> But again, I really have no strong feelings either way. We can go with  
> the first variant and add the second one (possibly replacing the  
> former one) if we need it later on. :)
>
>
> So, do you want to add it? :)
>   

Well I could do it, but I can't promise to do it today ;-).

// Johannes