On Thu, Feb 25, 2021 at 10:47 AM José Mejuto via lazarus < lazarus@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". Regards, Juha
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus