Jacek Laskowski

Maybe it is worthwhile to move the 'crypto' library to a new, separate repository? In a common, large repo it is difficult for anyone to find it

@Dmitry Arefiev Maybe now you can reply to this issue? I still fight with it.

History window: Old MMX 14:

$4000? Really?

Imho Indy is a better option because of its popularity and versatility. And I say this even though I use mORMot myself. But of course it would be good to leave support for newer versions based on System.Net.HttpClient. This means that it is best to pack the REST client into a new class and change its implementation as needed: Indy or System.Net.HttpClient

Maybe it is worth to surround the scope check by conditional directives? By default, the scope check would be enabled in debug and release, and for demanding users it would be possible to achieve maximum performance at the expense of a slightly more difficult configuration.

I use the latest version of MMX and the problem described above still occurs sometimes. Today I noticed an additional symptom. I have two methods in class, located next to each other, the same names, but the first one is generic and inactive (marked as a comment). After editing the second one and approving both were moved to the beginning of the class:

Sarina DuPont, comment from 5 months ago: "10.3.3 versions of Delphi and C++ Builder Community Edition remain available for download. 10.3.3 was an excellent release and Community Edition users can perfectly well continue to work with that release. The majority of customers who need the best performance, quality and features should be able to purchase the latest release. Our paying customers deserve a premium experience. That, coupled with increased non-compliant usage of Community Edition (which we're actively addressing with our legal team), has resulted in delaying a new release of CE. Over the coming months, we'll determine when a 10.4 version of CE will be released. Regards, Sarina"

@Kas Ob. Maybe you should put on a new thread with your proposal, this one concerns my proposal, ok?

Ok, I actually assumed that everyone uses lower case letters as prefixes But let's think about the cases. Let's assume that we want to use the letter 'a' as a prefix, in which case all the possibilities of the end result are: name -> aname Name -> aName Array -> aArray array -> aarray ?? When the beginning of the name already contains a small 'a' (in case of re-editing), it is enough to check if the beginning is consistent with 'a', only the last example introduces an ambiguity, because 'array' starts with 'a' and it is not known if it is a 'rray' with an added prefix or 'array' without a prefix. In this case, I would leave 'array' unchanged (which works well for editing the aarray parameter as well). The case with the prefix written in capital letters 'A': name -> Aname Name -> AName Array -> AArray ?? array -> Aarray In this case, the third case (Array) is ambiguous. I would leave it unchanged, similarly as above. These conditions do not seem very complicated, have I overlooked something?

As I wrote in the first post this functionality would be optional and configurable.

The Hungarian notation refers to prefixes identifying the type of variable, this is something else. In this case you would have all 3 kinds of prefixes marked as 'a'.

I have a proposal for a new functionality for MMX. It is a simple change, and for me, and I hope other users too, can be very useful. I use prefixes in the names of method parameters, I personally prefer the letters a, o and v for const, out and var parameters, respectively: procedure Somethinghing(const aInput : Integer; out oOutput : string; var vOther : string); Thanks to this, inside the body of the method, I know which parameter has which features and whether I can (var) or should (out) change it. This greatly improves code readability and error avoidance. Of course I write about myself 😉 I suggest adding a function to MMX that could be called "Forcing a parameter name prefix". Of course, the prefix (a, c and o) themselves could be set in the MMX configuration (just like the prefix for object fields). Additionally, in the configuration I would also give a checkbox "Force parameter name prefix", which would be the default value when editing the method (ctrl+E) and which could be incidentally unchecked or checked as in the picture: Using the "force prefix" option would work in such a way that if the parameter has some prefix (lowercase letters in front, before uppercase) they would be replaced, e.g. xParam -> aParam, xyParam -> aParam, and if the parameter has no prefix then it would be added, Param -> aParam Does this idea seem good to you and you would take it up?

https://www.thedelphigeek.com/2019/04/fastmm4-large-memory.html

Inline was added in D2005: https://edn.embarcadero.com/article/33050