EugeneK

Lol, we had to do the same migration at our company, complained to Atlassian that cloud Jira is super slow compared to old hosted one, their response - our code is very big and complex you should get a faster computer. And our company is much bigger than Embarcadero. Jira is dominating the market and there is no easy migration to something else, there is no reason for them to do anything right now.

To be fair not much they can do, Atlassian blackmailing everyone to move to cloud based Jira, so they have to use inferior system as customer facing.

It is a long standing bug, see https://quality.embarcadero.com/browse/RSP-25799 https://quality.embarcadero.com/browse/RSP-31289, probably won't be fixed anytime soon.

I've added "Embarcadero Customers" to sharing, so hopefully this helps.

I've seen people going old-school and posting +1 comments 😀

Don't know what to do, new system is very primitive, I don't see any options on the page different from other issues that are available to different people.

Allow for recursive directory search for units https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-940 These ones are in old system, so they are read only. I wonder should I copy these ones to new one? Add http status code constants to RTL https://quality.embarcadero.com/browse/RSP-35731 Add const versions of generic anonymous methods declarations https://quality.embarcadero.com/browse/RSP-33336 Decouple TService/TServiceApplication from VCL https://quality.embarcadero.com/browse/RSP-41813 Add immutable records (similar to C# readonly structs) https://quality.embarcadero.com/browse/RSP-34572

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

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.

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'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?

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.

I wish they added interfaces to existing RTL classes, this would be nice backwards compatible way to improve memory management.

You can take a different approach, these fields are reflecting some query, since you declare all the fields I assume query is static. This means that you can generate Delphi code based on this query, that will declare and assign all the variables, so you won't have to write it yourself and in addition this will make it easy to add new queries, and if you change query compiler will tell you about errors in dependent code.

Hi I noticed that in THttpCli 404 StatusCode is returned in many different situations like timeout/DNS resolution failure, which makes it difficult to diagnose issues because it is the same as legitimate 404 code from web server. Is it possible to change it to something else?