[Lazarus] TMask revisited

Juha Manninen juha.manninen62 at gmail.com
Thu Oct 21 20:37:32 CEST 2021


On Thu, Oct 21, 2021 at 11:30 AM José Mejuto via lazarus <
lazarus at lists.lazarus-ide.org> wrote:

> Now you need to match a string that starts with a number and the second
> char must be a letter, with a set it will be too large and unclear:
>
> "[0123456789][abcdefghijklmnopqrstuvwxyz]*"
>

With all Unicode characters included it would be even larger.  :)
Your code supports full Unicode also in the mask itself which is impressive.

I would like to get opinions of the "Legacy" constructors and functions in
the current code.
They use constant MaskOpCodesNoEscape which makes the mask behave more
close to the earlier mask implementation.
For example :
 constructor TMaskUTF8.CreateLegacy(const aMask: String; aCaseSensitive:
Boolean);
and
 function MatchesMaskLegacy(const FileName, Mask: String; CaseSensitive:
Boolean): Boolean;

As the comment for MaskOpCodesNoEscape says:
  // Interpret [?] as literal question mark instead of 0..1 chars wildcard.
  // Disable backslash escaping characters like "\?".
  // Leave out eMaskOpcodeAnyCharOrNone and eMaskOpcodeEscapeChar

The constructors and functions without "Legacy" allow backslash escaping
and treat [?] as a wildcard.
It can be seen as the default behavior because "Create" is the default
constructor name by convention. It is also the default behavior in José's
original code.
I allowed it because the new syntax is an improvement. It is intuitive and
more expressive.
Now, should we emphasize backwards compatibility and use
MaskOpCodesNoEscape by default?
The new improved syntax would then have constructors and functions with
different names, "Extended" maybe.
How does Delphi do it? Should we be Delphi compatible here?
Interestingly there are no standards for Mask syntax. They have evolved and
diverted freely. Thus we cannot follow standards.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211021/62911700/attachment.html>


More information about the lazarus mailing list