Re: [Lazarus] TMask revisited
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 mocOptionaChar to mocSet and added some comments in the code. @José: are these comments correct? TMaskOpCode=(mocAnyChar, //treat ? as a wildcard mocAnyCharOrNone,//treat [?] to match any char the absence of a char mocAnyText, //treat * as a wildcard mocRange,//treat [a-d] to match either 'a', 'b', 'c', or 'd' mocSet, //treat [ab] to match either 'a' or 'b mocNegateGroup, //treat [!a-d] to not match 'a', 'b', 'c', or 'd', but match any other char. Requires mocRange and/or mocSet mocEscapeChar); //treat EscapeChar (defaults to '\') in [a\-b] to match either 'a', 'b', or '-'. Requires mocOptionalChar enabled and mocRange disabled -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 (at least not as I expected): Opcodes: [eMaskOpcodeRange, eMaskOpcodeOptionalChar, eMaskOpcodeEscapeChar] Mask: [a\-z] // since '-' is escaped should match 'a', '-' or 'z' Matches Filenames 'a', 'b', 'c' ,'d' .. 'z', but not '-' Opcodes: [eMaskOpcodeRange, eMaskOpcodeOptionalChar, eMaskOpcodeEscapeChar] Mask: [a\-] //should match either 'a' or '-' EMaskError: Missing closing character "]" in mask (offset 5). Opcodes: [eMaskOpcodeOptionalChar, eMaskOpcodeEscapeChar] Mask: [a\-] //should match either 'a' or '-' Matches Filenames: 'a', '\' and '-' Q: eMaskOpcodeEscapeChar only treats '\' as escape char is eMaskOpcodeRange is enabled? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 (as long as you do not do mathematical operations with the value of that byte). Hello, The value was given just to group some things, originally they were constants, in theory values can be removed or changed (unless I forget something), they are used as a marker in compiled stream, like a command. -- -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 interpreting > the mask. > > Q1: is it possible to have the TMaskOpCode as an internal type in the > class (maybe in the protected part of the class definition)? > It seems it is not needed outside (as in the public part of the interface). > > If we did not already have the old TMaskOption type, I would actually > have liked to propose to rename the TMaskOpcodesEnum into > TMaskOption... > 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 remember many enums actually are class internals in José's original code (in GitHub). I moved them outside to create the constants more easily. Maybe they can be moved back to a class. You can experiment with it. You can rename other stuff, too, if you like. I will not touch it for a while now. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 of the unit. I've given it some more thought. 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 interpreting the mask. Q1: is it possible to have the TMaskOpCode as an internal type in the class (maybe in the protected part of the class definition)? It seems it is not needed outside (as in the public part of the interface). If we did not already have the old TMaskOption type, I would actually have liked to propose to rename the TMaskOpcodesEnum into TMaskOption... 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 (as long as you do not do mathematical operations with the value of that byte). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 disabled to not be interpreted as a mask char, so to allow granularity a name to that "feature" must be given. -- -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 by me. Hello, Trying to help, my variables notation (used across several languages) is: c* = Class variable l* = Local variable F* = Class published variable T* = Type, struct, record, set... e* = Enum value p* = Pointer Each language have its style rules, but as I'm using different languages (as many people) designed some little rules to help me in the future not to the style guide designers. Fortunately Lazarus IDE makes rename them very, very easy. -- -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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. Naming conventions. Typically we don't have the habit of haveing the literal phrase "enum" in our enum typenames. We also tend to adopt that enum names are derived form the typename in a manner like typename: TSomeType enum name: stXXX 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 of the unit. If we rename TMaskOpCode to TInternalMaskOpCode and rename TMaskOpcodesEnum to TMaskOpcodesEnum to TMaskOpcode and TMaskOpcodesSet to TMaskOpcodes (we tend to do that with sets of enums: set typename = typename+s), then the opcode enum names can be changed to moAnyChar, moAnyCharOrNone etc. So: TInternalMaskOpcode (integers) TMaskOpcode (the enums) TMaskOpcodes: set of TMaskOpcode Enum names: moXXX This would be more in line with our unwritten style guide (at least this is how I percieve it). Also we have shorter, yet not less intuitive, enum names. The same for TWindowsQuirks: TWindowsQuirks: enums TWindowsQuirks: set of TWindowsQuirks Enum names: wqXXX Yes, those are intrusive changes, and they add no functionality, nor do they fix any bugs, but this is the time to consider such a change. The new and improved (yes, improved) TMask with all new types won't be used very much ATM. In a few weeks or months this might not be the case anymore. Opinions please! Makes sense. -- 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] TMask revisited
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 lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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 the habit of haveing the literal phrase "enum" in our enum typenames. We also tend to adopt that enum names are derived form the typename in a manner like typename: TSomeType enum name: stXXX 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 of the unit. If we rename TMaskOpCode to TInternalMaskOpCode and rename TMaskOpcodesEnum to TMaskOpcodesEnum to TMaskOpcode and TMaskOpcodesSet to TMaskOpcodes (we tend to do that with sets of enums: set typename = typename+s), then the opcode enum names can be changed to moAnyChar, moAnyCharOrNone etc. So: TInternalMaskOpcode (integers) TMaskOpcode (the enums) TMaskOpcodes: set of TMaskOpcode Enum names: moXXX This would be more in line with our unwritten style guide (at least this is how I percieve it). Also we have shorter, yet not less intuitive, enum names. The same for TWindowsQuirks: TWindowsQuirks: enums TWindowsQuirks: set of TWindowsQuirks Enum names: wqXXX Yes, those are intrusive changes, and they add no functionality, nor do they fix any bugs, but this is the time to consider such a change. The new and improved (yes, improved) TMask with all new types won't be used very much ATM. In a few weeks or months this might not be the case anymore. Opinions please! -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
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). > > Because they are different beast in the code and in the syntax, many > times ranges apparently are syntactic sugar for sets, but ranges have a > begin and an end, and both have a mission, one, ranges, add clarity to > the desired match, and the second, sets, add flexibility to the mask write. > 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. since we are still looking for a better (?) name for the eMaskOpcodeOptionalChar enum: When eMaskOpcodeOptionalChar enables the use of [abcde] and eMaskOpcodeRange enables the use of [a-z] and syntactically there is a difference between ranges [a-e] and sets [abcde], then a potentially better name could be eMaskOpcodeSet(s)? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
