Talk:Record
Concerning the variant record example. The last bit reads: "It doesn't harm, whether the field marriageDate ist defined multiple times."
I cannot get FPC (3.0.0) to compile TPerson specifically because of the "Duplicate identifier "marriageDate"" error. Could you show us how it's done? the previous unsigned message was made by Finchley on 2017-07-09T13:42:25Z
- True dat. Kai Burghardt (talk) 23:02, 11 February 2018 (CET)
Record: Variable structure
Single
was used as identifier in a set! This is not recommended in Pascal. So I changed all identifiers in set 'maritalStates' to be prefixed with 'ms_'.
Response from User:Kai_Burghardt for undoing this change:
keep it simple [and Pascal does not define “single”, so there’s no reason not to name an identifier like that]
- Take a look at Record#Variable_structure and you notice that
single
is colored red. So this item has a meaning in pascal formatting. This is not good in an example, because noone should wonder why a maritalState is related to ObjectPascal. - Take a look at Data_type#Floating-point_types: in freepascal
real
is platform dependent. I would not recommend to use it. In the whole unit math you wouldn't find anyreal
. AlsoSingle
is defined in fpc/3.0.4/source/rtl/win64/system.pp according to Lazarus hint, although you are free to redefine it as it is done here. Also not good in an example. And then you should at least mention it. - If you paste the example in a new application and define somewhere: the user gets:
Income : Single;
Error in type definition
. Why would you introduce a source of unexplainable errors to new users? - Also it's good practice to prefix your enumerated type identifiers like:
bsSolid, vk_Escape, pf32bit
. Why not show good programming style to new users? - There is nothing simple in not using the last mentioned point. Instead, this would improve the readibility of the code - that is simple.
— Preceding unsigned comment added by Crore (talk • contribs) 2020-07-29T16:46:15
- Parentheses
(…)
don’t delimit a set, but in this case an enumeration type definition.- Actually, I didn’t notice that. I have protanopia (red-green color blindness) and red is the worst color for highlighting. Anyways,
single
is a Borland Pascal extension. The fact that GeSHi apparently colors this identifier differently doesn’t make it “more” Pascal-ish, nor is it any kind of special.
It is good practice to name identifiers in a straightforward manner, no negations and no ingenious synonyms just to avoid name clashes. There is a sophisticated scoping system in place, so use it.
I adapted this example from a (20+ year old) Pascal book. We may of course use a different example which still many people understand, i. e. why it is designed like that: I assume all people understand you’re either single, married, widowed or divorced. If you have a just as good example, don’t hesitate to insert it instead. - Au contraire, I would recommend to use
real
as much as possible. It is defined by Pascal thus guaranteed to be available with every compiler. I would hard-code the floating-point number’s precision (i. e. usesingle
) only if I knew I required precisely reproduceable results across various platforms (e. g. some statistics application). - Please don’t resort to whataboutism. The given examples are considered to be correct in their own right.
- Manually prefixing identifiers is actually a terrible practice, especially in a cryptic manner like that: There is
{$scopedEnums on}
which will automatically prepend the type’s name. However, this is “kind of” an advanced topic, so I wouldn’t like to clutter examples about record type definitions with details about enumeration type definitions, so it’s better to show a straightforward implementation of aperson
record and not bother about that.
- Actually, I didn’t notice that. I have protanopia (red-green color blindness) and red is the worst color for highlighting. Anyways,
- Kai Burghardt (talk) 18:15, 30 July 2020 (CEST)
- What do you refer to in your parenthesis remark?
- Don't stick to ISO 7185 from 1990. This site is about Free Pascal and therefore not every compiler has to be considered.
- Single was intentionally added to GeSHi Pascal formatting. This makes it special.
- floating point types Single is the first item
- wikipedia Free_Pascal
... Free Pascal adopted the de facto standard dialect of Pascal programmers – Borland Pascal ...
Free Pascal was created when Borland clarified that Borland Pascal development for DOS would stop ...
- Free_Pascal:
The language syntax is semantically compatible with Turbo Pascal 7.0 as well as most versions of Delphi
- WhatIsFP
... the Free Pascal compiler is a 16,32 and 64 bit Turbo Pascal and Delphi compatible Pascal compiler ...
... Free Pascal tries to implement a Borland compatible pascal compiler ...
- Turbo Pascal 7.0: Page 28
- GNU pascal Real-Types knows Single
- So the naming of
bsSolid, vk_Escape, pf32bit
shows bad practice? ... automatically prepend the type’s name.
How do you get this opinion?- It's not very cryptic to extract ms from maritalStates. Prefixes also make it easier to use Lazarus_IDE_Tools#Identifier_Completion.
--Crore (talk) 16:10, 31 July 2020 (CEST)
- Your edit summary said “Single was used as identifier in a set!” There is no set.
- Since when has GeSHi any authority about Pascal?
Single
is a regular identifier like anything else. It is perfectly legitimate to use it. - Choosing
real
oversingle
(or the other way round) is a design principle. It isn’t about restricting oneself to the ISO definitions. If you need a specific precision, then use an appropriate type. On some platforms, however, there may be nosingle
available. But this isn’t the issue here. - Yes, (manually) duplicating data is bad practice. Even the
T
prefix is unnecessary. The compiler knows a certain identifier refers to a data type. - What opinion?
- I guarantee you if I walked up on you on the street and asked you “What does
ms
stand for inmsSingle
?” you had no idea.maritalStatus.Single
, on the other hand, is definitely more explanatory.
- Again, feel free to replace the example by something better.
- Kai Burghardt (talk) 23:08, 2 August 2020 (CEST)
- Also, despite its name “syntax highlighting”, this formatting does not actually highlight syntax. The definition of an enumerated type doesn’t expect a list of type identifiers, but merely identifiers that weren’t defined in the current scope. The source code as it is is accepted by any compiler. There are no syntax errors. It would be great if what we call “syntax highlighting” would actually highlight the true syntax, but for simplicity/performance it just highlights an approximation. Statistically, in most cases,
single
will refer to the data type; however, GeSHi is “too dumb” to recognize a variable declaration, a formal signature, ortypeInfo(…)
expression, these are in fact ([almost] the only) occurrencessingle
refers to the data type.
Kai Burghardt (talk) 13:02, 4 August 2020 (CEST)
- Also, despite its name “syntax highlighting”, this formatting does not actually highlight syntax. The definition of an enumerated type doesn’t expect a list of type identifiers, but merely identifiers that weren’t defined in the current scope. The source code as it is is accepted by any compiler. There are no syntax errors. It would be great if what we call “syntax highlighting” would actually highlight the true syntax, but for simplicity/performance it just highlights an approximation. Statistically, in most cases,
- You're both right, so I fixed it for you Trev (talk) 14:04, 4 August 2020 (CEST)
- Well, uhm... This is what I earlier meant by “It is good practice to name identifiers in a straightforward manner, no negations and no ingenious synonyms just to avoid name clashes.”.
unmarried
is a negation ofmarried
. Also, unmarried may also refer to divorced or widowed people, so this is inconsistent with the other membersmaritalStatus
defines. But, anyway, it works. As an example it works, so I won’t insertsingle
back in again. You, Crore, are nevertheless welcome to provide a better, easier to understand example.
Kai Burghardt (talk) 14:32, 4 August 2020 (CEST)
- Well, uhm... This is what I earlier meant by “It is good practice to name identifiers in a straightforward manner, no negations and no ingenious synonyms just to avoid name clashes.”.