Re: [Lazarus] Masks: ConstructLegacy
28.10.2021 0:33, Bart via lazarus пишет: On Wed, Oct 27, 2021 at 11:17 PM Juha Manninen via lazarus wrote: Attached the codetools popup for TMask.Create constructor. I would think it would be clear enough? 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. 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? 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). -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
28.10.2021 0:17, Juha Manninen via lazarus пишет: On Thu, Oct 28, 2021 at 12:02 AM Bart via lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: Attached the codetools popup for TMask.Create constructor. I would think it would be clear enough? 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. 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. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 11:17 PM Juha Manninen via lazarus wrote: >> Attached the codetools popup for TMask.Create constructor. >> I would think it would be clear enough? > 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. 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? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Thu, Oct 28, 2021 at 12:02 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Attached the codetools popup for TMask.Create constructor. > I would think it would be clear enough? > 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 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 9:55 PM Juha Manninen via lazarus 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? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 10:06 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > You totally lost me here. > IMHO there is no need for CreateExtende or similar new constructor. > Why not? THis is what we currently have. > > TMask: > constructor Create(const aMask: String; aCaseSensitive: Boolean; > aOpcodesAllowed: TMaskOpCodes); virtual; overload; > 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 > 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. > 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 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 8:46 PM Juha Manninen via lazarus 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. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 6:44 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > The extended syntax would have another constructor. > > Not really sure what you mean by that. > There would be a constructor named CreateExtended or CreateAdvanced or similar, allowing the new nice syntax. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 2:09 PM Juha Manninen via lazarus wrote: >> 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? > > > That is fine with me. The Create constructors would then behave like > CreateLegacy now. 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. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 2:50 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > 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? > 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 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Masks: ConstructLegacy
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? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
