Dalija Prasnikar

First, this sounds like premature optimization. Yes it is 6 times slower, but you are talking about milliseconds for huge number of objects. Next, if you really need to optimize for speed, you can completely remove getter and setter methods. That is the beauty of Delphi - it does not need them at all and you can freely add getter and setter methods later on (if needed) without breaking the public API. Inline approach can solve the immediate problem, but keep in mind that inline directive is just recommendation for the compiler and under some circumstances such methods will not get inlined (though compiler will give you hint in those cases). Essentially you are writing a whole a lot of code for nothing.

If you care about quality it does not really matter where the bug was reported. What matters is that people who need to know are aware of the bug.

It is not what you wrap, but how you wrap it. There were some issues with SourceTree related both to embedded version of Git and GUI itself. I don't know all the details, but the latest version works fine again, and yes it was never really lightning fast.

Nitpicking... at least you can jump...

Can't argue that... Problem is that expansion to other platforms started as customers request. If we all knew then what we know now, maybe things would play out differently.... on the other hand, maybe not... when you have need to support other platforms and your toolset does not have them, you have to find some that does... when you start moving away, sometimes you may be inclined to move away completely. Also, development team shrinking process happened after expansion to other platforms... Quite unexpectedly, if I may say, because at that point it should have been obvious that more platforms means more work and more work requires more people, not less. We can argue here until the end of the world, but how can you argue anything when actual events (decisions) defy all logic. For all we know, maybe even without additional platforms Windows side would be in similar position as it is now.

Lack of resources, maybe... they have to provide proper support for platforms they have expanded to, Apple and Google have their requirements and their own toolsets and don't care much about other people's problems - with notable exceptions - but again only when it is in their own interest. In that light... Windows can wait for any improvements, regardless of how many customers would actually benefit from better Windows support.

Maybe somebody at Unity didn't have to ask because there is huge number of Unity Android games with large distributions out there. Google knows what kinds of applications they host and how many don't support 64bit.

How is poll going to help? Whatever Embarcadero has planed, it is far too late to make any meaningful rescheduling.

In latest roadmap it was newer scheduled for 10.3, but for some 10.3.x update Android 64bit is scheduled for 10.4 AFAIK, this roadmap as far as those compilers are concerned is still valid. When exactly any of those releases will actually hit the road, anyone's guess is as good as mine. macOS 64-bit is needed not just for developing macOS apps, but also internally for iOS development toolchain and supporting iOS 11 and iOS 12 simulators. Last year, there was public beta for Delphi developers on active subscription that allowed publishing Android applications built with beta on Google Play store. If nothing else similar scenario can be expected for Android 64 bit compiler. I know this is far from ideal... but... To be on the safe side... anyone should prepare for the worst and release any major updates before August deadline...

No. It could not lead to freeing object that is still in use. But there is another thing that can happen here. Under ARC compiler all object references (variables) including local ones are initialized to nil before they are used and you can safely call Free on nil object. In first example, if TMyObject constructor fails and raises an exception obj.Free will be called on uninitialized reference. If that uninitialized reference is nil by any chance, you will get lucky, if not you will trigger AV. But that does not fully explains random AVs, unless it happens after your "expected" exception from constructor.

DisposeOf is only ever needed on ARC compiler. There using Free or DisposeOf are different things. On classic non-ARC compiler DisposeOf translates to Free, so it does not matter which one you use, it will behave the same. Access violations mean that you are accessing object instance that is already released. There are two likely scenarios: 1. you are calling Free somewhere on object you are still using. On ARC compiler such instance would be kept alive (because Free just nils the reference and does not destroy the object if you have another strong reference(s)) 2. you are calling DisposeOf on object you are still using, which on ARC compiler does not fully destroys the object (just calls destructor) but the object instance memory is accessible and intact so you can call methods on it (as long as you have some strong reference to that instance), or access fields without causing AV, unless you access something that has been explicitly destroyed in destructor. Random behavior complicates things... such errors can be caused by threading issues.

If you invalidate flag sitting inside interface when form is going to be destroyed, then you know form is no longer valid and you can skip calling methods on invalid reference.

Your idea with reference counted object (you have to pass it as interface and not as const to increase its reference count) and invalidating a flag will serve the purpose. I don't use OmniThread library, so I don't know if there are some built in mechanisms to take care of such cases.

Android officially does not have splash screen support. Various frameworks only simulate splash screen while they load... so just use sizes Delphi asks and that should be it, The best is to use simple logo centered on black background (similar to default FMX splash). It is the least intrusive and will look good on various setups. If your application needs longer initialization, then make main FMX form as light as possible and then implement proper splash inside that can show progress and can be better customized.

Well, MDI applications were deprecated a long time ago and Delphi IDE is seriously lagging behind in getting proper high DPI support. What I mean is that actively developed applications should be eventually updated to fully and properly support high dpi and not rely on this fix. I know, it takes time to do so... Now, it is much clearer. Can you please add that picture to your QP report.

Maybe, but this setting is merely a quick fix for seriously outdated applications. I am not sure how much sense it makes to add such support in IDE. Again, dpiAware and dpiAwareness elements and their values are separate from gdiScaling element and setting that appears in application properties dialog. If I understood you correctly you would like to add gdiScaling element automatically when "System Aware" option is selected, but that might have negative impact on some applications that use such setting. I am saying might because I don't have any particular example where it will fail, but if that setting would be completely compatible, then MS would not introduce additional flag, they would just apply enhanced scaling to all applications with corresponding dpiAware or dpiAwareness settings.

That part solely depends on a parser.

It means that if (more like when) data definition/structure changes, it is harder to provide backward compatibility support for JSON comparing to XML. Simplest example: { "id": 1, ... id is integer here... if you cannot easily change it to string. <id>1</id> - format stays the same, you can parse it like integer or like string. Of course, you cannot just parse "abc" as integer, but... Also, XML structure can be more easily verified and you have greater options to manipulate and transform its content without parsing it first. You can also more easily pull only chunk of data and parse just that part. All that is probably not highly important for settings because that kind of data is usually not too complex or too large. I don't want to hijack this thread... so... just wanted to say that choosing between JSON and XML is not as simple as it may look. It is not "JSON is always better" situation.

But not very resilient to changes.

To achieve what you want you can also use custom manifest instead of automatically generated one. Also, your request is a bit confusing - System (Enhanced) scaling in application properties dialog has nothing to do with System Aware setting you can choose for manifest. Auto generated manifest sets only dpiAware and dpiAwareness elements and you want ability to include gdiScaling element.

iOS 12.x and iOS 11.x simulators are not supported because they require macOS 64bit support that is on the roadmap for 10.3.x update (most likely 10.3.2) You can use iOS 10.x simulators. https://community.idera.com/developer-tools/b/blog/posts/build-ios-11-ready-apps-with-rad-studio-10-2-1 https://quality.embarcadero.com/browse/RSP-21654

Decisions like that are rarely made by single person. Marco is there as company representative, so he speaks for the company and his personal views may be different ones. Also circumstances change, people change, decisions change. There is nothing unusual about that. You can hardly go forward if you keep focusing on the past.

Thank you for offering technical proof (in your own model) of what I have been talking about all along. ARC and non ARC objects can exist side by side, but they don't mix well. And that fact brings all kind of trouble like I mentioned earlier - you have ARC based objects when you don't want them to be automatically managed, you have non ARC objects when you would like to have their memory managed automatically, you have TComponent ownership model on top of all that. You have to deeply know with which kind of objects you are dealing with. That is not simple. Languages with fully automatic memory management models may have their weaknesses with which you may have to deal from time to time, but generally you can just write code without micromanaging objects memory. Anyway, I rest my case... otherwise I would just end up repeating myself.

You may want to rethink this statement since Delphi had more than just manual memory management since Delphi 4.

We already have mixed memory management model where ARC based classes coexist with non ARC based classes. Now different people have different views how well that model works, but generally it doesn't. It is complex model that requires plenty of knowledge to use it safely, and even if you know how to use it, you constantly have to jump through the hoops because quite commonly you don't have what you really need in particular code. You will either have reference counted class when you don't need one, or you will have non reference counted when you could really use it. On top of that you have TComponent based ownership model that will get in your way when you least need it. OK, it is not all that bad... but situation is far from ideal. Then we got ARC compiler, that solves all that duality problems perfectly. To be clear, no memory management model is perfect for all use cases, but in case of Delphi full ARC was the best fit in terms of existing code bases and integration with existing ARC based model for interfaces. But, it turned out that even though it was the best fit for majority use cases, changes required in existing code bases were too huge, also it required learning and adopting to new ways of writing code. Guess what? ARC was not welcomed by majority of Delphi developers that lead to decisions Macro explained in his blog post and decision that ARC compiler is deprecated. So, after this ARC compiler failure. You want to implement your completely different mixed model that would still suffer from various problems - because no matter how far you go (and even if you can make your model work slightly better that the current one) you still cannot successfully mix ARC and non-ARC objects. Not only you didn't solved original problem, you also introduced another one - your model is completely incompatible with existing code and would require even greater changes to existing code bases. For me that is end of story. This is not viable option, no matter how you turn it.