Dalija Prasnikar

AnsiString as such makes sense only on Windows, but I don't think removing it is necessary. More problematic are plethora of "compatibility" functions named AnsiXXX that work on string and not on AnsiString. Not really, because LOGI expects pointer to a string not TBytes. So that code does not compile. Not everything can be squeezed in TBytes and not everything makes sense to be bytes. LOGD logs text messages, the fact there is conversion to UTF8 involved is just example. You might as well have API that would directly use UTF-16 encoded string, or you may already work with UTF8 encoded strings.

I always though Delphi is the root ancestor to C# The only commonality C# has with C are braces.

Delphi is much more low level than C# or Java or JS. It has all those string types for a reason and for interacting with particular OS and other APIs. When you need to handle such low level things in Java or any other language the whole thing usually ends up being a memory and performance hog, just like it happened in initial mobile compilers, because you cannot deal directly with particular string representation and you have to juggle data back and forth. And handling encoding and other issues is never easy there, too. Some features can be implemented through helpers, but you cannot accomplish everything in satisfactory manner. For instance getting pointer to UTF8 string to use with OS API you needed additional TMarshaller variable. And not only you need the variable, but the code behind it is slower. Without 8-bit string compiler support procedure Output(const aMsg: string); var M: TMarshaller; begin LOGD(M.AsUtf8(aMsg).ToPointer); end; With 8-bit string compiler support procedure Output(const aMsg: string); begin LOGD(PUtf8Char(Utf8String(aMsg))); end; As far as new users are concerned, they only need to know and use generic string type. If and when they get in touch with other string types, it is pretty simple to explain what is purpose of each type and how is is used. We have different integer types, we have different string types.

I don't remember anyone complaining The though process was a bit different. Mobile compilers were supposed to attract new generation of developers. To do that it needed to have some competing features. One was automatic memory management (hence ARC), another one was streamlining string and array indexing - hence zero-based strings. Short strings store length at index zero, so they were completely incompatible with that goal. AnsiStrings with ANSI encoding are not something that exists on mobile platforms, so they were deemed as unnecessary, too. So 8-bit strings were removed. Unfortunately, what they didn't take into account is impact on existing codebases. The same ones that were supposed to run on all other platforms (yes, you couldn't reuse GUI), but there is not reason to throw away non-GUI code. Zero based strings wreak havoc in string handling, causing subtle bugs all over the place. Most people after they learned about it would just turn the damn thing off. Removing all other 8-bit strings was also a mistake, because 8-bit strings make a whole a lot of sense in cross-platform, especially on Linux where UTF-8 encoding rules. So while throwing out AnsiString as such made sense, the rest did not. This is also why 8-bit strings were reintroduced, even before ARC was removed - which happened for completely different and unrelated reasons. And the last, but not the least. TBytes are completely different beast from strings. It is not that just that handling functions were missing. TBytes don't have COW, and also debugger support is extremely limited and you cannot easily inspect textual data stored within. And we all know how many new customers they attracted to Delphi because it was suddenly cross-platform.

For iOS 15 you need Xcode 13. You can find direct download links here https://developer.apple.com/download/all/

There seems to be more general problem with updating Xcode. Just few days ago I spent 6 hours installing Xcode 12.5.1 It managed to finish only after I deleted old Xcode from applications folder and cleared the trash.

Use Supports function var LTheme: ITheme; begin if Supports(Obj, ITheme, LTheme) then LTheme.UpdateTheme; end;

We have no idea. New roadmap hasn't been published yet.

No. Because you need type for as operator. (intf_1 as IMyInterface).C; But you also need to add GUID to your interface declaration because without it it cannot be identified.

Try changing more settings. At some point they will be persisted. Another option is to import 10.4.2 settings or change problematic options directly in registry, before you start IDE

This sounds like same issue: [REGRESSION] Editor Font setting is not persisted. https://quality.embarcadero.com/browse/RSP-34854

No, because there are none.

Borland is dead.

Africa, Egypt. There was the largest library in ancient world.

Not really. https://jlericson.com/2021/08/24/git_rewrite_1.html https://jlericson.com/2021/09/06/git_rewrite_2.html

Yes. Usually in separate repository, but sometimes in the same as the project which is using them. Anything I can lay my hands on... my book manuscripts, documentation, illustrations and images, 3rd party source code, my own source code or all kinds, recipes, to do lists, basically all kinds of documents that can (or cannot) change with time.

Yes, it can. But the problem is not in hiding your constructor. Every class in Delphi descends from base TObject class, whether you explicitly state that in class declaration or not TSingleton = class TSingleton = class(TObject) And TObject has public constructor Create. That means its every descendant and consequently every other class in Delphi has public constructor Create. Since it is public it is accessible and you cannot prevent people using it. So, even if you hide constructor in descendant class, someone can write TSingleton.Create and this will not call your hidden constructor, but TObject default constructor. The only way to hide that TObject constructor is to add public constructor with same name in your class, like in example I posted. But then you again have problem with having publicly accessible constructor and people can instantiate more than single object instance. If that public constructor raises exception, then at least code will fail at runtime showing that this constructor shouldn't be used.

There is another way to prevent instance creation - or at least misuse - having public constructor that raises exception. TSingleton = class private class var FInstance: TSingleton; constructor CreateSingleton; class destructor ClassDestroy; public constructor Create; class function Instance: TSingleton; static; end; class destructor TSingleton.ClassDestroy; begin FInstance.Free; end; constructor TSingleton.Create; begin raise Exception.Create('Singleton instance cannot be directly constructed'); end; constructor TSingleton.CreateSingleton; begin // actual constructor end; class function TSingleton.Instance: TSingleton; begin if not Assigned(FInstance) then FInstance := TSingleton.CreateSingleton; Result := FInstance; end;

You cannot make such singleton in Delphi. Public TObject constructor will be always visible and you cannot hide it, The only way to disable access to the constructor is to define singleton API as interface and have public factory method that returns interface, and then put class implementation inside implementation section of the unit making it inaccessible to the outside world.

Creating separate objects would be my preferred approach, they are not that heavy to have significant impact on performance. ExecuteAsync is .... I have no words for describing it... maybe some people would like it, but for me it is useless addition. If you want to run rest it in the background thread simplest code is to just run the whole thing in background thread and then synchronize only if you need to synchronize some piece of code. With Execute you get clean code under your control where it is obvious what runs where and how you need to handle things, with ExecuteAsync you first need to learn how to use it properly. I would forget about it as it does not offer any advantages. I am glad if it helped to give you some insight, because I was confused about what you are aiming at. You can ask only very specific questions on Stack Overflow. For instance your initial question here would be definitely off topic on Stack Overflow. If you can create some minimal code example something in line what I have posted here as example, then you can aske whether you are doing it correctly and whether it is thread safe. It is also good to point to specific parts of the code you are not sure about. When it comes to thread safety it depends on the actual code and sometimes people don't add enough code. On the other hand adding too much code is also a problem because it is harder to get clear picture id there is plenty of code. For instance, if you need to populate UI, you don't need to show 50+ lines of UI related code. One is enough. The quality of answers also very much depends on the quality of the question. If answering requires a lot of guessing you will less likely get good answers. Few lines of code speak better than words 🙂 Don't describe your code, write it - even if it is just a rough concept. Then build the rest of the explanation on top of that.

I don't understand what is your problem. You asked whether those classes are safe, we answered they are not. Every thread needs to have dedicated object instance for each one - client, request, response. Even if you use ExecuteAsync, you cannot share that instance. So basic example would be for i := 0 to Data.Count-1 do begin RunRest(Data[i]); end; procedure RunRest(const s: string); begin TTask.Run( procedure var Client, Response, Request... begin Client := TRESTClient.Create(s); try Response := TRESTResponse.Create(Client); Request := TRESTRequest.Create(Client); // other rest setup... Request.Execute; // process Response, if needed you can do that in Synchronize call - if you are interacting with GUI then you definitely need to Synchronize here finally Client.Free; end; end); end;

Konopka VCL Controls are not available for Community Edition. You need to have purchased license (see under Subscription) to get them: https://getitnow.embarcadero.com/KonopkaControls-270-6.2.3/

TFunc is anonymous method, which are backed by interface. So GUID you get from field type is not for ITestA,, but for TFunc<ITestA>. I don't think you can get generic part out from parameterized type. In theory TFunc has Invoke method, so if you could get information on its result type, you would have ITestA. But I couldn't get Invoke information out of RTTI. The real question here is what you are actually trying to do. Your test code is obviously just a test - you already know that TForm1 MyField works with ITestA, so if you can make small test case for your actual use case, maybe there is a way to get information you need. For instance if your form would be generic, you would more easily get what you need because you would have T to work with TForm1<T> = class(TForm) private MyField:TFunc<T>; end;

None of those components are not thread-safe. They can be used in background threads, but each thread needs to have their own instances. Yes, you need separate client objects for each thread, too. If the StringList is not shared and you generating unique file name is coordinated between threads, so there cannot be any overlap, then it is safe to save inside thread.

Right... I completely misinterpreted what you were saying. I guess it is "I am reading words, but their meaning is not arriving in my brain" day...