Leaderboard

Following on from my comment about complexity, I'm wondering what's wrong with this: You don't need to remember anything. Why are you seeking complexity here? You seem to be trying to solve a problem that simply does not exist.

My take is what he really wants in code completion that actually works? It bugs the hell out of me that when I'm typing an assignment statement and the left side is an enum, that code completion offers all sorts of crap that is not relevant. If the type isn't found, tell me that.

No, not all the time but the more I do it, the more I like it. You were wanting a better system of not having to remember a specific enumeration like htTemplate. One suggestion was to just create a HTML related unit that contains the main generic HTML related types that you want to use so you can remember the general unit name and then lean on code completion to find the type/enumeration. Create a naming system that you like for these types of units, something like HTMLTypes.pas, HTMLUtils.pas, HTMLShared.pas, or whatever naming style you prefer and then you can type HTMLTypes. and invoke code completion to get all of your shared HTML related types and drill down to the one you want. If you have HTTP related items you also create HTTPTypes.pas (or whatever) and then DBTypes, EmailTypes, etc. These shared units usually have type definitions with little code. One code smell is if you are including a bunch of code in one of these shared units, then that code should be split out to its own unit (likely several new units.) Defining where the code should live is a primary key to the ability to maintain the code over time. It also helps you code much faster if the organization makes internal sense. Choice 1 is one unit with every single line of code. Choice 2 is a separate unit for every class or type definition, no matter how small. There's a balance somewhere in the middle, leaning greatly towards 2.

The enumerated type has been removed in oberon. When Niklaus Emil Wirth came to us in Tomsk. We asked him a question, the reason for this was done? We got an answer about his shortcomings. 1. Very often, an enumerated type cannot be extended, This may be due to the fact that it is from a third party library and the domain of its values is already sealed. 2. A set of constants can successfully perform the same role. 3. One and the same concept is often used in different classifications, which leads to the growth of similar names with distinguishing prefixes. 4. The prefix is essentially the same vicious Hungarian notation LPStrZ_to_hell For convenient use, a related set of constants can be placed in a module or record. The record will act as a namespace. Here we will not be limited to expanding the list of values. Also, we can always add related methods for working with these values. THTMLType = record public const Template = 0; Static = 1; Header = 2; Custom = 3; end; Criticism The enumeration type is traditional in advanced programming languages, is widely used and is often taken for granted. However, this type is also not without criticism from programming theorists and practitioners. So, when developing the Oberon programming language, enumerated types were included in the list of features that were removed from the language. Niklaus Wirth, the language developer, gave the following reasons: “In an increasing number of programs, the ill-considered use of enumerations ... leads to a population explosion among types, which, in turn, leads not to clarity of programs, but to verbosity” [1]; when an enumeration type is exported by a module (that is, it becomes part of the interface), the general rule is violated - the type export command simultaneously exports all its elements, while for all other types, the type export hides its internal structure; from the point of view of ensuring readability of programs, nothing prevents you from using just a group of jointly defined named constants instead of an enumerated type, especially when there are language mechanisms such as modules or classes. On the other hand, for example, in Java, which initially did not contain an enumerated type, this type was subsequently introduced for reasons of not only convenience, but also reliability: the problem of using named constant groups instead of enumerations is that there is no compiler control as to the uniqueness of values constants, and the possibility of random assignment to variables of values that do not correspond to any of these constants.

If you are using relative paths and of course an SCM, you start out by creating a copy of the original project in SCM, check out that copy to a new directory and then simply do all the changes necessary: Rename the project, delete any files you don't need, optionally rename the files etc.

Members of an enum are not objects. For ex. I have IDs of syntax relations of words in a natural language (about 200 IDs). The numerical values of the enumeration members are not important to us, only their names matter. Therefore, there is no need to specify integer values for each member of an enum in your program. 1., 2., 3., 4. - it was the answer to the words of Wirth, which you quoted earlier. Enumerations were invented in order not to use ordinalities of its members directly. And so as not to (accidentally) add, subtract and divide them like numbers. This is Pascal where type safety matters. Headers can use enums as well. It depends on how the С-language headers are translated into Pascal code. With enumerations, you can reorder old values as you want. And nothing will break if the ordinalities are not directly used anywhere. Overcomplication, misuse of software entities.

Very interesting. By the way, I look at the code of your library, a lot of good ideas are used in it.

How to check the zero-based index. How many comparison operations it takes to check the occurrence of a value from 0 .. Count - 1. index, fCount: Integer It would seem that it could be easier and here we write the code: Assert((index >= 0) and (index < fCount), 'Array bounds error') This is exactly the message I saw when rangecheck was on. on my very first and favorite compiler for Pascal - 1 for PDP-11. First love does not rust. This is equivalent to two checks and if you open the CPU window we can see that this is indeed the case. We use commands that take into account the upper sign bit. Oz.SGL.Test.pas.459: fCount := 5; 0066E55D C745F405000000 mov [ebp-$0c],$00000005 Oz.SGL.Test.pas.460: index := -2; 0066E564 C745F8FEFFFFFFF mov [ebp-$08],$fffffffe Oz.SGL.Test.pas.461: Assert((index >= 0) and (index < fCount), 'Array bounds error'); 0066E56B 837DF800 cmp dword ptr [ebp-$08],$00 0066E56F 7C08 jl $0066e579 0066E571 8B45F8 mov eax,[ebp-$08] 0066E574 3B45F4 cmp eax,[ebp-$0c] 0066E577 7C14 jl $0066e58d 0066E579 B9CD010000 mov ecx,$000001cd 0066E57E BABCE56600 mov edx,$0066e5bc 0066E583 B818E66600 mov eax,$0066e618 0066E588 E853C8D9FF call @Assert Some microprocessors have special commands to check the entry of the index, who can perform this check with a single command. But if you use the command of comparing unsigned numbers we can simplify the expression and write the following code Assert(Cardinal(index) < Cardinal(fCount), 'Array bounds error'); and then we can do the same check using a single comparison. This reduces the price of the check by exactly half. Oz.SGL.Test.pas.462: Assert(Cardinal(index) < Cardinal(fCount), 'Array bounds error'); 0066E58D 8B45F8 mov eax,[ebp-$08]. 0066E590 3B45F4 cmp eax,[ebp-$0c] 0066E593 7214 jb $0066e5a9 0066E595 B9CE010000 mov ecx,$000001ce 0066E59A BABCE56600 mov edx,$0066e5bc 0066E59F B818E66600 mov eax,$0066e618 0066E5A4 E837C8D9FF call @Assert Usually when debugging I try to remember to enable rangecheck. But in the release version all checks are usually turned off. That is, in training flights we fly with a parachute. But in the combat flight (in the release version) we leave this parachute at home. Then hackers use it to crack through our programs. Do not forget to check at least the input buffer of your program.

1. You cannot extend a set of constants if they are defined in a record type in a third party library. There is no record inheritance. 2. An enumeration give us more type safety than a set of integer constants. 3. Scoped enumerations. 4. I like prefixes. But if not, see 3. I use enums with 100 or more members. If instead of them I used named integer constants, adding and subtracting them, there would be many hard-to-find errors.

I use TMS TadvStringGrid when I need to do this, but it is not free and not available on its own. It can build the combobox with an entry for every different value in the column, or you can override it to create entries manually such as 1-20. 21-40, >40, and filter them yourself. It puts an icon in the header row which you click on to filter. I am sure that there are other grids available from other vendors with this capability, but I happen to use TMS

And I thought enums and the possibility to build sets of enums is one of those unique features in Delphi that many other languages such as C++ don't have hence you have to and/or with damn bitmasks....

Changing NA to Nada gives same result. But - adding the "unit scope" works. CommandType := ScopedEnumsWithoutT.CommandType.NA;

That's XE7. It seems to me to be folly to design your code based on an IDE tooling issue, and especially one which is soon to be resolved. Further, the issue at stake here, as always when coding, is far less about the experience when writing code, as the experience when reading code. It's not worth it to reduce the readability of your code to give a minor easing to your experience when entering the code.

https://blogs.embarcadero.com/new-getit-web-portal The portal https://getitnow.embarcadero.com/

You can make use of pre-compiled DCUs for these libraries.

Well, we have thousands of meaningful and reasonably obvious names (within their context) - but yeah - remembering them gets harder every year. Age takes its toll. 😛 But - Code Insight should work whether you are assigning or passing as a parameter. Unfortunately, it has often put the enumerated values a long way down the list of candidates. We've only started using 10.4.1, so the jury is still out on this issue, but the LSP has been less than rock solid so far.

Give types a meaningful and obvious name. Then you don't have issues remembering them.

Hi there, I'm sure most of you were aware of @Dave Nottage and his very helpful (live-saving) Kastri(Free) projects. Now with the presentation of the Memorizer, there are certain discussions about issues in the cross-platform world. Same as Dave I try to postpone permission requests to the bitter end, just before touching the hardware. For camera, sensors, etc. thats usually no issue. The problems may start when using local notifications, or related permissions, like Bluetooth and location. The local notifications permissions are fired right at startup, and thats annoying. You can imagine if you need a few permissions at startup, then they all will appear, and the user has to click them away before showing any useful screen. But for local notifications permission this might be maybe the right way too, because in mobile you also can run in foreground or background. So I would like to discuss the possibilities and pros and cons we have, for the permission settings from a users point-of-view. 1. Ask permission right after startup (as is now) - this is annoying to the user, especially if several requests appear one after the other - works in all cases, also for background mode, as it forces the user to decide - its a little like the old "Android way", permit all before use anything, but Androids style has changed meanwhile (for good reasons) - sometimes the app runs in background, and has no other chance to notify, than by local notification So the local notification permission shall be given at startup, to ensure this works. 2. Ask permission short before usage (in foreground) - thats what I like too, users shall decide each function before they use it. - but when moving to background w/o giving permission before, this might fail. A user cannot give permission while in background mode, the function simply fail or crash. 3. Ask permission short before going to background - this is not possible, because the app cannot do much when changing the states, especially no long-lasting alerts. 4. Allow permission in a special setup dialog - This is the "windows" setup philosophy, I think very much out of fashion in mobile: Force the user to visit setup first. - This will solve the issue in 2.), but I really try to to avoid this forcing of "setup" style design. Are there any other ideas or use-cases ? So far I think 1.) (as is) has its need too, and its not easy to cover all use-cases with one solution in mobile, there are too many options. Beside that, Android and iOS might have different philosophies as well, howto get them all under one umbrella ?

In your example, HTML is a field variable of the TReportEnums structure with the specific type defined to be THTMLType. You are trying to access it as an Enumeration and not as a variable. Delphi offers meta classes where you can define a variable to be a class type such as: TMySomethingClass = class of TMySomething, and you can define a variable of type TMySomethingClass, but this only works with classes. AFAIK there's no similar thing for records. Not a great solution, but if you could group your defines in one class you could get code completion from a master class like: TMasterRecordTypes = class type THTMLType = (htTemplate, htStatic, htHeader, htCustom); TSecondRecordType = (srOne, srTwo, srThree); end; vHTMLReportType := TMasterRecordTypes.THTMLType.htTemplate; Or just put all your related record types into a particular unit and use the unit name as the scope, which is how it's normally done. vHTMLReportType := MyUnitName.THTMLType.htTemplate;

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Scoped_Enums_(Delphi)

This is how it looks like for me (Delphi Rio 10.3.3). Unit Aliases is something I have never needed to use so far.

Firebase covers a broad range of subjects: https://firebase.google.com/ Which one(s) are you referring to?

Having a unit called "utils" in the GetIt package is not really a bright idea by Embarcadero. At least they could have prefixed it as getit.utils.

The idea was to write all units in all uses clauses with their full names instead of relying on the value in Unit Scope Names.

Do you have any actual numbers (compilation time improvement) for any of these. We are gathering some from different developers, and at this point the top one is UnitFindByAlias. Now workaround is stop using unit aliases, but it is our top issue to fix in the compiler. We also have another not in the fix pack that we are rolling out early in a patch, affecting unit cache for large projects and causing compiler time to grow (dramatically!) over successive builds If any other the fixes above (or any not listed) has a very significant effect, we can prioritize it. We are focused on reducing and eventually removing the need of the fix pack, but it takes time as some of the fixes are fairly direct (and many have been implemented in the past) while others require significant rework and spawn threads to do some of the work -- something valuable but requiring extensive testing