EugeneK

I understand this, I changed it. I'm talking about default value, good that I noticed it, if someone won't notice it can be unpleasant surprise if people rely on using specific OpenSSL version.

I think this should be commented out by default, I want to use OpenSSL version that I control. {$DEFINE OpenSSL_Resource_Files}

This should be updated with link to new quality portal https://qp.embarcadero.com/

BTW any reason why AnswerBodyTB rather than AnswerBodyTBytes or AnswerBodyBytes? makes it less readable and not consistent since it is AnswerBodyStream, not AnswerBodyTS

For me it is alternative for AnswerStream, so there is no need to create/dispose stream if there are already TBytes to send.

Hi Can we add THttpConnection.AnswerBytes with TBytes parameter same way as TSocket.SendTB

I'm not sure you understand my point. What I'm saying is that Embarcadero can theoretically hide ability to implement this interface manually and all existing code that uses anonymous methods in documented way will still work. Or they can change interface, say, rename Invoke to InvokeEx for some reason. So manually implementing this interface is a hack that can randomly stop working. Although I agree that probability is low that they will change it.

I'm not saying doing it without interface, I mean hiding this implementation detail from the users. I.e. not allowing to manually implement this interface in code. This won't break any documented uses of anonymous methods.

But this implementation does not have to be accessible as interface to end user for it to work.

I think anonymous methods will still work without ability to explicitly use them as interfaces. I could not find it being used in this way anywhere in Delphi RTL.

So it is not officially supported and theoretically can be changed?

In Dalija Prasnikar's smart pointer unit here https://github.com/dalijap/code-delphi-mm/blob/master/Part5/SmartPointer/uSmartPtr.pas#L8 following code is used ISmartPointer<T> = reference to function: T; TSmartPointer<T: class, constructor> = class(TInterfacedObject, ISmartPointer<T>) basically anonymous method declaration is equivalent to interface. Is it documented somewhere? I tried looking at Interfaces and Anonymous method sections in documentation but can't find anything.

I meant in my own code, for example in unit tests sometimes it is easier to provide mock of some class rather than constructing it. It is an outlier but it exists, which means it is possible, and I dread thinking what it would have been using it if it would not be interface based. Well in my case it would have been an innocent bug because it was assigned just after creating, so no information was lost, but application would have been working instead of shutting down every few days. That's really nice, I wonder why they won't add something like this to RTL. But you agree that it is less readable than using interfaces. But why would you want to typecast back to TStrings? By backwards compatible I meant that existing code won't break and if you need to use TStrings you just use continue to use TStrings as before, but in new code if you declare it as IStrings you can pass it to procedures that accept IStrings. Main purpose is separation of interface from implementation so you can use TMySuferfastStrings or TUnitTestThisClassStrings and your code won't need any changes, I guess I prefer way of C# where all collections are interfaced, rather than C++

Of course you don't just add interface to declaration, some work is needed but all your description does not say that it can't be implemented in backwards compatible way. And doing it class by class is much easier than adding ARC to whole compiler. All classes that take TComponent owner already need to be manually freed when passed nil as a parameter. There could be bugs because of double free/memory leak because of this too. Exactly! That's the whole point, it also has other advantages, like ability to provide different implementation for classes. And TComponent seems to already implement interface reference counting, so maybe all that is needed to add interface implementing public methods. You never really need automatically manage memory, you can always free it manually it just a big source of bugs. I think goal of compiler developers should be to give people options to avoid them and write simpler code. Just now I found 10 year old bug where TStrings object was assigned to already created object causing memory leak, this kind of bug is almost impossible to find and it would not be a problem if it was IStrings instead. For smart pointers I don't really see a way to use them as elegantly as interfaces, at least with current Delphi language. I don't agree with this, but Embarcadero devs seem to agree, since they closed my ticket about it.

I was thinking something like TXmlDocument/IXmlDocument, if you use TXmlDocument you continue using regular Create/Free or component ownership and if you use IXmlDocument it is reference counted.