On Fri, Oct 15, 2021 at 1:55 AM Juha Manninen via lazarus <lazarus@lists.lazarus-ide.org> wrote:
> > On Thu, Oct 14, 2021 at 7:57 PM Bart via lazarus > <lazarus@lists.lazarus-ide.org> wrote: >> >> You have changed the existing interface for both TMask and the >> Matches(Windows)Mask(List) functions. >> TMaskOptions has been removed. > > > It can be added for compatibility. Please do. But, also feel free to deprecate them. >> Noticable the ability to NOT interpret [] as a set in the mask has now >> disappeared. > > > How should a range / set [] be interpreted? ?? [az] is interpreted as either a or z by default Diasbling use of sets would interpret this as literally [az] (4 chars). > Now the same thing is done by passing MaskOpCodesDisableRange constant where > type TMaskOpcodesSet parameter is used. > TMaskOptions can be restored for compatibility. OK. >> You have sacrificed consistent and reliable behaviour for gain of speed. > > No Bart, that is not true. This is not only about speed. The old Mask was > buggy and limited. I agree about the limited part. Not many bugs were filed against asks unit, and I did not encounter them, but my locale is Ducth and the ocaasional non-ascii I happen to have in my filenames all process correctly. > Please run the test project testmasks.lpi. All current tests pass. > Now checkout a revision before my Mask changes, eg. e5ed5082d and run tests > again. Many errors. Notably there was no support for Unicode. I'll have a look. > Yes, there should be an option for backwards compatible syntax, like "[?]" . > However the small changes in the syntax can be seen as improvements. > There already is a define for converting "[z-a]" to "[a-z]". Why a define? Shouldn't that better be configurable at runtime? >> José's code also catered for some odd DOS behaviour where a mask like >> >> 'file.txt?' actually matches with the filename 'file.txt' and a mask >> 'file?.txt' would match 'file1234.txt' (but not 'file12345.txt'). >> That would be rather counter-intuitive to most users. >> I did not test (it was in one of the "quirks" settings) if it behaves >> like this by default, but that should IMHO not be the case. I tested it now, and by default it returns fals for those cases. > Yes it is counter-intuitive but it matches with Windows' behavior. > You can test it on a DOS/Windows cmd prompt. file?.txt matches file.txt and file1.txt, but not file12.txt, so ? as last char before . is treated as no or 1 character. > That is why it is called TMaskWindows. The normal TMask behaves more > logically. > The "quirks" prove that Jose has tested it a lot. > > About the speed: TMask can also be used without disk file operations. Then > the speed matters. Yes it can, but it was desigend for filemasks (see the original parameter names). > I will look at the compatibility issues and possible bugs tomorrow. Thank you. I did not study th enre code at length, but it looks quite a bit more complicated to me than the old one. Not sure if I will be able to contribute to it anymore. -- Bart -- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
