Hello guys
Hello guys,
My personal wishlist for Godzilla release, no order of preference:
- Declare local variables with value https://quality.embarcadero.com/browse/RSP-14867
- Enumerable constraint to generics https://quality.embarcadero.com/browse/RSP-12767
It could use some kind of duck typing to discover if a type is enumerable without needing to implement IEnumerable interface as it is already implemented for the for each loop.
- PPL Task Continuation and Cancellation Token support https://quality.embarcadero.com/browse/RSP-13286
- Nullable Types and Null Propagation https://quality.embarcadero.com/browse/RSP-13305
- Iterators (aka. yield) https://quality.embarcadero.com/browse/RSP-13341
- ARC support for all platforms (including Linux) \o/
:D
My personal wishlist for Godzilla release, no order of preference:
- Declare local variables with value https://quality.embarcadero.com/browse/RSP-14867
- Enumerable constraint to generics https://quality.embarcadero.com/browse/RSP-12767
It could use some kind of duck typing to discover if a type is enumerable without needing to implement IEnumerable interface as it is already implemented for the for each loop.
- PPL Task Continuation and Cancellation Token support https://quality.embarcadero.com/browse/RSP-13286
- Nullable Types and Null Propagation https://quality.embarcadero.com/browse/RSP-13305
- Iterators (aka. yield) https://quality.embarcadero.com/browse/RSP-13341
- ARC support for all platforms (including Linux) \o/
:D
I hope you are wrong about the first.
ReplyDeleteAlexandre Machado I don't like to play with manual memory management :(
ReplyDeleteWhy ARC only on linux? ARC for any platform will reduce the differences between the platforms.
ReplyDeleteSo ARC for all or no ARC at all should be the way to go. This kind of mix up is just crap.
My vote is on going ARC at all
Oliver Münzberg Sorry man, my comment was misleading I have fixed this :D
ReplyDeleteMy vote is on going ARC at all too :D ARC everywhere :D
Do you know how many 3rd party source code would break with this? Do you really think that, for example, DevExpress will invest huge amounts to make their source code compatible with ARC (I guess 99% of their revenue comes form .NET land these days)? Honestly, if you don't like manual memory management, I'm afraid you have chosen the wrong language. Pascal is not for you. Accept it.
ReplyDeleteThe JSON library also need some more work (looking at JSON.Net) as the Task library (looking at .net System.Threading) which include CancellationToken and Continuation but also that nice LongRunning feature (which will only run the task code inside an anonymous thread and not inside the thread pool)
ReplyDeleteAlexandre Machado Don't be afraid of ARC. In most cases there will be no code change at all.
ReplyDeleteOliver Münzberg Are you sure? Interesting.... Indy source code contains exactly 209 {IFDEF USE_OBJECT_ARC} compiler directives. And this is because "there won't be code change at all". Imagine if the changes were severe? BTW, Indy source code has been abstracting everything for decades which makes it less prone to severe changes. However, source code change is the easier part. The (much) harder part is testing.
ReplyDeleteAlexandre Machado Did you only count the occurance or did you have a close look why they use that ARC switch at that position?
ReplyDeleteOliver Münzberg I counted the occurrences and I don't need to have a closer look because I work with Indy every single day. So I know why most are there. The point that you are really missing here is that: whatever level of real difficulty it might have, from any point of view, if you have to add 209 IFDEFs to your code, changing 37 files, the change is not trivial and testing cannot be underestimated. Anyone saying the opposite is just being naive.
ReplyDeleteInteresting times we are living... I have to defend things like: "You should not break 20+ years code bases for nothing", like I'm the one saying nonsenses here... LOL
ReplyDeleteYou both haven't pointed a single benefit that would come from that, unless "I don't like to do manual memory management".
Anyway, I won't start a war because of it. In the end, I know that EMBT won't do that on Win32/64 not because they are wise, but because they don't have the resources to do that ;-)
Alexandre Machado Would you bet on your last point?
ReplyDeleteOliver Münzberg I would bet on the following: Linux will be ARC (cause it is easier for them, huge mistake), Win32/64 will stay as it is (the same reason).
ReplyDeleteAlexandre Machado As Uwe Raabe stated a couple of days ago Emba already have a compiler with ARC for windows - just for internal use.
ReplyDeleteThis is not a question of resources, just of let's do it.
Again, you underestimate testing. How many hours do you think that EMBT spent testing RTL and the whole VCL in that compiler?
ReplyDeleteAlso, whether this compiler is production ready is a mystery. Given the fact that even things considered "production ready" turned out to be more like "alpha test ready", I wouldn't be surprised if the compiler is only capable of doing very basic stuff.
Alexandre Machado The Win-Arc-Compiler is probably not going to target VCL code! Only the current Win32 and Win64 compilers are allowed for VCL. All the other compilers are only to be used with FMX. So Win-Arc is not a replacement for Win32 with VCL, but rather an additional platform for FMX. As far as I see there will never be an Arc-based compiler targeting VCL. Actually there is simply no need for it.
ReplyDeleteUwe Raabe That's what I'm talking here, since the beginning....
ReplyDelete