[Lazarus] TMask revisited

[Bart]

On Thu, Oct 14, 2021 at 6:54 PM Bart <bartjunk64 at gmail.com> wrote:

> This was discussed at length in february.

>From the discussion in february:

Feb 24 11:22 AM
> And also define if a compatibility break is a bug in the new code or in
> the old code. In example my mask supports (there is a define to disable)
> "[z-a]" converting it to "[a-z]" which is a compatibility break. Also
> there is the support (also can be disabled) for the mask "[?]" which is
> the counterpart for "*" but with one char position.

Current behaviour of sets and wildcards should not be changed by default.
E.g. TShellTreeView and TShellListView use the Masks unit to populate
the tree/view.
An option to have the behaviour you described would be OK, the
TMaskOption can be extended for that.

--------

Feb 26 7:15 PM
The normal way of doing this is:
Deprecate the function in question, but do NOT kill it's functionality.
Add a useful deprecated message.
Remove the function in the next major release (deprecate in 2.1, and
so 2.2, only remove in 2.3, so it'll be gone in 2.4).
Simply removing functionality like you have done now will alienate
users from Lazarus, since apparently "we" cannot be trusted.

Juha: you seem to be obsessed with speeding up string handling code.
This is not really a problem as long as you are not deaf to arguments
against your changes.
You introduce new bugs, remove old features, all for the sake of speed.
-------------------------

Let me be very clear: I am NOT against improving and expanding TMask
and associated functions.
Overhauling the "matching algorithm" so that it is no longer O(n^3) or
O(n^4) is a good thing.
Speeding up string handling functions is most of the time also a good thing.

Breaking things in the long run also may be acceptable.
Breaking them over night, unannounced and especially __removing
existing functionality__ is a no-no from my point of view.


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.

-- 
Bart