Re: [Lazarus] Masks: ConstructLegacy

2021-10-27 Thread Maxim Ganetsky via lazarus

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

2021-10-27 Thread Maxim Ganetsky via lazarus

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

2021-10-27 Thread 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?

-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Masks: ConstructLegacy

2021-10-27 Thread Juha Manninen via lazarus
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

2021-10-27 Thread Bart via lazarus
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

2021-10-27 Thread Juha Manninen via lazarus
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

2021-10-27 Thread Bart via lazarus
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

2021-10-27 Thread Juha Manninen via lazarus
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

2021-10-27 Thread Bart via lazarus
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

2021-10-27 Thread Juha Manninen via lazarus
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