On Sat, Oct 23, 2021 at 10:39 PM Juha Manninen via lazarus
wrote:
> In 964d5f4d69 I changed most names as you suggested.
> The original TMaskOpCode is now TMaskParsedCode because it is not related to
> the other enums directly.
> I did the changes before reading your last mail.
I renamed
On Tue, Oct 19, 2021 at 10:44 AM José Mejuto via lazarus
wrote:
> With "eMaskOpcodeRange" and "eMaskOpcodeOptionalChar" enabled to match
> "a" or "-" or "z" the "-" must be escaped (something like regex) using
> the escapechar, by default "\", in this way "[a\-z]".
That does not seem to work
El 23/10/2021 a las 22:18, Bart via lazarus escribió:
Q2: @José: the TMaskOpCode enums are indexed, and there is a gap in
the index. Is the index necessary for the code to work?
Is the gap necessary?
In the Add() method, the enum is cast to a byte, this should also work
if no indices are used
On Sat, Oct 23, 2021 at 11:21 PM Bart via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> AFAICS the TMaskOpCode and TMaskOpcodesEnum types are not related at all.
> TMaskOpCode is some kind of internal identifier in the internal mask
> representation, whereas TMaskOpcodesEnum are options for
On Sat, Oct 23, 2021 at 12:22 PM Bart wrote:
> Then we have TMaskOpcode and TMaskOpcodesEnum types.
> The first one is more or less an internal type.
> The latter one is for common user interface.
> Since TMaskOpCode is used in the interface part of TMask, we must have
> it in the interface part
On Sat, Oct 23, 2021 at 6:16 PM José Mejuto via lazarus
wrote:
> Because in the code each syntax piece can be enabled and disabled, even
> "*" and "?" can be disabled to not be interpreted as a mask char, so to
> allow granularity a name to that "feature" must be given.
Yep, OK.
--
Bart
--
El 23/10/2021 a las 12:02, Bart via lazarus escribió:
I can understand why having [a-e] is good (and better than [abcde]).
I was just confused by the fact that these had different names.
Hello,
Because in the code each syntax piece can be enabled and disabled, even
"*" and "?" can be
El 23/10/2021 a las 12:22, Bart via lazarus escribió:
On Sat, Oct 23, 2021 at 12:02 PM Bart wrote:
since we are still looking for a better (?) name for the
eMaskOpcodeOptionalChar enum:
This brings me to another point, and please, please, please don't see
this as criticism of feel offended
On Sat, Oct 23, 2021 at 12:22 PM Bart wrote:
> So:
> TInternalMaskOpcode (integers)
> TMaskOpcode (the enums)
> TMaskOpcodes: set of TMaskOpcode
> Enum names: moXXX
Maybe better make that mopXXX, as not to confuse them with old moXXX
TMaskOption enums.
--
Bart
--
23.10.2021 13:22, Bart via lazarus пишет:
On Sat, Oct 23, 2021 at 12:02 PM Bart wrote:
since we are still looking for a better (?) name for the
eMaskOpcodeOptionalChar enum:
This brings me to another point, and please, please, please don't see
this as criticism of feel offended by me.
On Sat, Oct 23, 2021 at 12:22 PM Bart wrote:
> Naming conventions.
Also: we typically have the convention of nameing fileds in a class Fxxx
Here we have cXXX and eXXX.
Again: not meant as crtitcism.
--
Bart
--
___
lazarus mailing list
On Sat, Oct 23, 2021 at 12:02 PM Bart wrote:
> since we are still looking for a better (?) name for the
> eMaskOpcodeOptionalChar enum:
This brings me to another point, and please, please, please don't see
this as criticism of feel offended by me.
Naming conventions.
Typically we don't have
On Thu, Oct 21, 2021 at 10:29 AM José Mejuto via lazarus
wrote:
> So the question is, why sets if ranges can be used ? Because sometimes
> you need to exclude strings that starts with number 1:
>
> "[0234567989][a-z]"
>
> > Naming them different just confuses me (which probably is my fault).
>
>
13 matches
Mail list logo
