[Lazarus] unit Masks vs. unit FPMasks

Juha Manninen juha.manninen62 at gmail.com
Thu Feb 25 10:39:55 CET 2021

On Thu, Feb 25, 2021 at 10:47 AM José Mejuto via lazarus <
lazarus at lists.lazarus-ide.org> wrote:

> In fact I think that the whole unit is needed. It has (info for other
> readers) 3 classes TMaskUTF8, TMaskAnsi and TMaskUnicode, maybe
> TMaskAnsi can be omitted but UTF8 and Unicode should be present. Many
> times TMask is used over zillions of strings, converting Unicode to UTF8
> (for UnicodeStrings and WideStrings) is time consuming, much more than
> the masking itself in most cases.

UTF8 is also Unicode, one of its encodings.
The name UnicodeString is misleading. It should be UTF16String.
Please remember our Unicode solution uses UTF-8. It is done by changing the
default encoding of AnsiString and triggered by the same LazUTF8 unit that
is used by Masks unit. Everything is UTF-8.

I suggest to keep the 3 classes and create a new TMask one which mimic
> the behaviour of current TMask, disabling the masking extensions (escape
> char, [?],...) which is very simple as you only need to subclass the
> Create method, mask compilation happens at first use time, not at
> creation time.

I can include the TMaskUnicode class there if you want, although its name
is also misleading.
TMaskAnsi must be left out. It has no use with our Unicode solution.
TMaskUTF8 I have renamed to TMask in my tests. It replaces the
current TMask which supports Unicode only partially.
I could make an alias type
  TMask = class(TMaskUTF8)
but why should I? Basically every String in our Unicode system has UTF-8
encoding. No need to have a special mask class for UTF-8.

This way current code using TMask will behave 99.9% identical, but an
> user that needs to mask other strings can use TMaskUnicode, in example,
> and activate or deactivate other extensions.

Where do the other strings come from? Anyway TMaskUnicode can be included,
no problem.
I am not sure we want a new TMask to behave 99.9% identical with the
current one. The new one has some clear improvements.
Interestingly there does not seem to be any standard for the mask syntax.
So we cannot be compliant to any "standard".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210225/b49178a2/attachment-0001.html>

More information about the lazarus mailing list