"The first we’ll be tackling is custom managed records, that is the ability to define a default parameterless constructor, a destructor and a copy operator for any record type."
"The first we’ll be tackling is custom managed records, that is the ability to define a default parameterless constructor, a destructor and a copy operator for any record type."
and
"We are also integrating a number of items from Andreas Hausladen’s IDE Fix Pack, which we licensed earlier this year."
https://community.embarcadero.com/blogs/entry/august-2018-roadmap-commentary-from-product-management
I'm in heaven! Finally! YESSSSSSS!!!!!
and
"We are also integrating a number of items from Andreas Hausladen’s IDE Fix Pack, which we licensed earlier this year."
https://community.embarcadero.com/blogs/entry/august-2018-roadmap-commentary-from-product-management
I'm in heaven! Finally! YESSSSSSS!!!!!
Custom managed records can have a wild variety of uses indeed!
ReplyDeleteSince Windows 3.1? 95? i have been positive about OS vendors consolidating various initiatives. Of course, they should credit those that should be credited. Regarding such a beast as Delphi it is unavoidable/important that the vendor picks up and is inspired by what the community produces. Otherwise things will become to segmentet, like in the JS library world atm. The attitude from Emba towards Hausladens work seems to have shifted in the more productive direction!! I remember blog-post from Marco (or other semi-official writings) that said thing in lieu with "only if nothing else works [after three weeks on the phone with our support staff], you could try to install the IDE Fix pack". Repeating myself to be absolutely clear, credits must be applied where those are due.
ReplyDeleteI was contemplating moving the gist of my projects from Berlin to Tokyo. Perhaps i'll wait for 10.3.1.
Given the fact that the records get more power, I'm wondering if anyone still needs the classic Delphi objects, or they can be painlessly removed from the compiler and the language? As well as Pentium-safe FDIV, Look for 8.3 filenames also, Assignable typed constants, Complete boolean evaluation, Long strings by default (always ON), Strict var-strings.
ReplyDeleteAlso I do not see much sense in storing a code page in the AnsiString type. This only adds unnecessary runtime checks. The encoding of strings should be monitored by a programmer himself, and use appropriate encodings in suitable places.
On the other hand, we have things that were touted previously, like 64bit OS X support and nullable types, being deferred. I noticed Marco talking about Quality, Performance, Stability again too. And still no commitment to rewrite the dang compiler, get rid of the .NET dependencies, consolidate the parsers, port to Firemonkey for cross-platform.
ReplyDeleteIt feels like Wimpy from the Popeye comics, who always said "I'll gladly pay you Tuesday for a hamburger today." Lots of vague promises for the future to distract from the failure to deliver what they promised before.
T n T Old style objects know OO (inheritance, virtual methods), so they still can't be replaced painlessly with records or classes. Of course it's better to switch to classes where you need OO, and replace the remaining old style objects with records, but that can be a non-trivial and error prone endeavour.
ReplyDeleteAnd in D2007 there were some internal compiler errors that forced you to write "object" where record should have worked.
ReplyDeleteThese custom managed records sound like RAII to me - yeah!
ReplyDeleteT n T 'I do not see much sense in storing a code page in the AnsiString type' - having the original UTF8String back as a type alias for the original AnsiString would be rubbish, because it would remove any compiler assistance for properly converting to and from UTF-16 without confusing UTF-8 with CP_ACP.
ReplyDeleteSince D2009, if you have a UTF-16 string (i.e. WideString or UnicodeString), and cast it to UTF8String while assigning to a UTF8String variable, you get UTF-8; before D2009, if you used the same code, you'd get CP_ACP.
Chris Rolliston UTF8String is for UTF-8, AnsiString is for CP_ACP. While internally these string types the same, we don't need to store UTF-8 in AnsiString, nor ANSI in UTF8String.
ReplyDeleteWhen we cast UniStr := string(AnsiStr); the compiler should convert CP_ACP to Unicode. And when we write Utf8Str := UTF8String(UniStr); the compiler should convert UTF-16 to UTF-8. It's as simple as ABC.
Wow, overriding record assignment (I believe that is the said copy operator)! Better late than never!
ReplyDeleteT n T that's what it does though in the current implementation... Not sure what your point is, to be honest...?
ReplyDeleteChris Rolliston My point is there is no need to store the codepage in an every single string value. As well as the element size. I was against it from the start. This is 4 bytes wasted in an every allocated string, and unnecessary runtime checks.
ReplyDeletePrimož Gabrijelčič Sorry for the offtop, I fully share your enthusiasm about the new improvements in the record format.
Uli Gerhardt So, object types are supported for backward compatibility only. Their use is not recommended. (It's from the Docwiki). Unwillingness or inability to convert objects into classes is the only argument, why they are still here.
ReplyDeleteI guess, after adding constructors and destructors to the record type, will there be a possibility to create our own optimized LightString type on the record basis without the code page and the size of element inside?
ReplyDeleteT n T My thoughts exactly. With custom managed records it can be possible to write simple types (like ansistring), even nullable types and more complex one with less overhead.
ReplyDeleteI'm sorry not all features will make this next release, but that'a also a community request. We asked (a lot ) for bug correction and improvement over new (buggy) features.
I (still) have faith 10.3 will be about quality, stability and performance.