Hi,

The new masks unit has several CreateLegacy constructors (and some *Legacy* functions).
They call the new constructros with mocEscapeChar disabled.

Wouldn't is be a bit more logical to exclude mocEscapeChar form the MaskOpCodesDefaultAllowed constant, since we'ld like to have the default behaviour as compatible as possible?

Since most of this code will be used for filename matching, escaping in most common practice won't be necessary.
Also, in existing code people may have mask with '\' as intentionally as a PathDelim, and this would break that.

If we leave things as is, then the question remains: how long do we keep the *Legacy* constructors and functions?

On Wed, Oct 27, 2021 at 2:50 PM Bart via lazarus <

That is fine with me. The Create constructors would then behave like CreateLegacy now.
The extended syntax would have another constructor. I was pondering this same topic in an earlier post.

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

Yes, that sort of was the objective.

The extended syntax would have another constructor.

Not really sure what you mean by that.
The "default" constructor is the one with the TMaskOpcodes (/TWindowsQuirks) parameters.

To be even more backwards compatible, mocRange should be disabled as well. I'm a bit reluctant to do so, as having ranges is quite an improvement over the old implementation (which had only sets). Possible problem is the '-' inside a range: this would be no problem in old code, but can raise exceptions in the new code.

On Wed, Oct 27, 2021 at 6:44 PM Bart via lazarus <

There would be a constructor named CreateExtended or CreateAdvanced or similar, allowing the new nice syntax.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211027/6ebe151c/attachment-0001.html>

PM Juha Manninen wrote

There would be a constructor named CreateExtended or CreateAdvanced or similar, allowing the new nice syntax.

You totally lost me here.
IMHO there is no need for CreateExtende or similar new constructor.

THis is what we currently have.

TMask:
constructor Create(const aMask: String; aCaseSensitive: Boolean;
aOpcodesAllowed: TMaskOpCodes); virtual; overload;
TMaskWindows:
constructor Create(const aMask: String; aCaseSensitive: Boolean;
aOpcodesAllowed: TMaskOpCodes; aWindowsQuirksAllowed: TWindowsQuirks);
TMaskList:
constructor Create(const aValue: String; aSeparator: Char=';';
CaseSensitive: Boolean=False;
      aOpcodesAllowed: TMaskOpCodes=MaskOpCodesDefaultAllowed);
TMaskListWindows:
constructor Create(const aValue: String; aSeparator: Char=';';
CaseSensitive: Boolean=False;
      aOpcodesAllowed: TMaskOpCodes=MaskOpCodesDefaultAllowed;
      aWindowsQuirksAllowed:
TWindowsQuirks=WindowsQuirksDefaultAllowed); reintroduce;

These __are__ the extended constructors for aal the fancy new/extended stuff. They are called by all the other constructors that only have the old parameters.

So we have backwardscompatibility and extended capability just with all constructors named simply Create.

On Wed, Oct 27, 2021 at 10:06 PM Bart via lazarus <

Why not?

THis is what we currently have.

I understood you will change constructor Create() to support the backwards compatible syntax.
Now there is CreateLegacy() to make it easy and intuitive to use. The same way a new CreateExtended() would make the new syntax easier to use. Such a constructor is handy and intuitive especially when code completion is used. A user sees alternative constructor names right away. A sign of an intuitive well designed API is that you can select methods and properties etc. with code completion by their names without referring much to documentation. At least you then get an idea of what to search from the documentation.

These __are__ the extended constructors for aal the fancy new/extended

The idea was only to offer an intuitive API which gives a hint there is something extended available, just like CreateLegacy() gave a hint there is the good old legacy syntax available.

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

PM Juha Manninen wrote

The idea was only to offer an intuitive API which gives a hint there is something extended available, just like CreateLegacy() gave a hint there is the good old legacy syntax available.

Attached the codetools popup for TMask.Create constructor. I would think it would be clear enough?

On Thu, Oct 28, 2021 at 12:02 AM Bart via lazarus <

Ok, if you say so. :)
It is clear for people who know the details already. For new users there is no hint of an extended syntax.
Anyway, we can consider it as an advanced feature which requires users to study deeper. No problem.

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

I'm OK with leaving them in, but in time they should be removed. CreateLegacy in version 3.6 is going to look a little bit "off".

We want people staring to use the "new" syntax (that is: use the additional last parameter(s)) as fast as possible. Maybe deprecate them in 2.5 and remove in whatever we release after 2.4?

28.10.2021 0:17, Juha Manninen via lazarus пишет:

I like Bart's proposal.

This syntax is extended only for now, in a year it will be perceived as pretty much standard, so such constructor division (Create/CreateExtended/CreateLegacy) will itself be considered a quirk. ;)

Anyway, we can consider it as an advanced feature which requires users to study deeper. No problem.

28.10.2021 0:33, Bart via lazarus пишет:

I don't see the need in CreateLegacy/CreateExtended constructors as far as backward compatibility is maintained (it is the case as far as I understand). Just commit your Create constructors refactoring and document the changes (and update release notes).