Dalija Prasnikar

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.

Valid questions... Embarcadero would have to appoint gatekeepers - probably their employees, although here they could use knowledgeable community members, but again those community members would have to report back to Embarcadero. For every point release maintaining interface compatibility is imperative. So there would have to be stable interface compatible version branch, and unstable interface breaking branch for future point release. From previous points, it is clear that only current release would be maintained. Any back-porting would have to be done by Embarcadero respecting older release interface compatibility. Probably very few (and more critical patches) would be applied to older versions and only few releases back (maybe even just one - depending on the point release frequency) Access rights - once you put code out it is hard to revoke access, and maybe it would make little sense for doing so. As far as initial access rights are concerned - while it would be nice if everyone could have access, realistically it only makes sense to give access to people that have current (or one older) release. You have to have means to contribute and if you are sitting on Delphi version that dates 5 years ago, you cannot contribute in meaningful manner to current and future releases. I know that people would love to have fixes for older versions, but I don't think amount of effort needed for such back porting would be sustainable. At least not for Embarcadero. What community in general could do in that regard - I don't want to speculate (including legal reasoning) At the end even now, we all have the sources, and nothing prevents people to organize some dark web code patching.

I am not sabotaging anything. I am merely presenting the facts that must be taken into account. Without that it may look like open sourcing the compiler is just one GitHub click away and Embarcadero is not doing that "good" move on purpose because <insert conspiracy theory du jpur> Also, when it comes to sabotaging, like I already said, you don't need any help in that area, you are perfectly doing that yourself. Your request lacks any real arguments and is basically insult to everyone working at Embarcadero.

Seriously???? You would leave five year old alone in control of the house when parents are away? Actually, it would be more like leaving the five year old with matches and can of gasoline. Let me say it again: Somebody (Embarcadero employee), extremely knowledgeable in particular code base would have to be gatekeeper - managing pull requests and communicating with community in general. That somebody would have to be top gun compiler engineer, someone from existing team who knows code base well, not someone who would they just throw in working for peanuts. So yes, under current circumstances that would take valuable resources away from current compiler development. And that is something we (or Embarcadero) cannot afford at this time. Yes, it would be good if Embarcadero would expand their core teams. That would be good move regardless of open sourcing . But even if they manage to hire good engineers today, it would still take quite some time before such expanded team could bear the burden of open sourcing. LOL And leaving amateurs to rampage all over the compiler, yeah, that would end really well. As far as RTL/VCL/FMX is concerned, it is not about catering for all old versions in existence out there. It is about going forward, so no compiler version would not pose a problem.

Yes, but sometimes it takes several iterations for some fix, or needed feature to end up in release. And patching on your own takes time. If everyone has to do it that is huge waste of time.

My comment under the QP request that explains my stance on the matter. I don't want to enter into endless discussion there because it is ultimately the wrong place. @Marco Cantu enabling access to compiler (or any other sources) and allowing community contributions does not mean giving it for free. You can put up any license terms you want. I know that enforcing license is harder than having closed source, but people that will violate such licenses will just use cracked versions anyway - that is far simpler that rebuilding compiler on their own, only handful of developers would go that route. While Delphi compiler code might be worth studying for those interested in compilers, I highly doubt there is any ground breaking technology there worth stealing nowadays. From that perspective opening compiler (or other sources) does not seem like showstopper. @All however, open sourcing (I will use that term, regardless of what the actual licensing model would be) is not as simple as mere dumping source on GitHub. Somebody (Embarcadero employee), extremely knowledgeable in particular codebase would have to be gatekeeper - managing pull requests and communicating with community in general. In order to open sourcing to be successful endeavor there must be significant number of contributions made, without that - the whole thing makes no sense for Embarcadero (and for the community as well - beyond satisfying everyone's curiosity). In that case gatekeeper(s) will have their hands full. Not to mention that for every successful contribution, there will be countess others that will have to be reviewed and rejected for various reasons. That part introduces additional cost to Embarcadero and ability to develop code on their own, because part of the resources that would be used to developing in house will have to be spent for community interaction. Eventually, gains from community code can outweigh the costs, but that would take some time. Also, in code base that large, it may take years for community to start contributing in meaningful manner. And gate keeping would have to start immediately. There will be developers that will jump in from the start trying to fix their pet pevee without looking at bigger picture (breaking things like bull in a china shop). Now, that might look like - it it would take long time, let's start early then... but like I said, initial cost in terms of resources might be too high. Especially, now when there is a lot of work to do on various compilers - new ones (Android and macOS 64bit), including introducing some new features that are already in the works. From that perspective, open sourcing compiler in general... yes, but I don't think now (or any time soon) would be the right time. Right now (or soon enough), opening up sources to RTL/VCL/FMX would be much better move - we already have the sources, we already know our way around them. Community at large can more successfully contribute to those sources than to the compiler. Again, that kind of project would also have some initial cost, but I believe it could pay off much sooner. Open sourcing is the double edged sword - in order to be successful it takes resources that would otherwise be spent on in house development (with much higher initial progress rate). But the push for open sourcing (because, of the illusion that community can fix things faster and better) is greater in times when internal resources are spread thin, than in the times when everything works peachy. So it is kind of damned if you do damned if you don't situation.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Methods_(Delphi) Overload is used when you have methods with same name but different parameters. Override is used when you have methods with same name and same parameters, but one is in parent class (marked as virtual or dynamic) and other is in child class and you want to override method functionality in child class.