Smaller, cleaner RTTI probably NOT coming
I got an email from Barry Kelly in response to my last post:
I can’t comment on this article as it requires the commenter to be
logged in, and registration is disabled.There are no plans for a more compact RTTI format. I’d love for there to
be, but the backward compatibility concerns are simply too large.
However, as more code relies on higher-level RTTI constructs, the scope
for freedom there increases incrementally. That’s all I was trying to
say.— Barry
*sigh* I thought I’d fixed the comments thing. Anyone’s supposed to be able to post here with just a name and email address. That’s why registration is disabled: no one should need to register! Looks like it got reset somehow during the last WordPress update. 🙁
As for the RTTI, I guess I’m not surprised by that. Backwards compatibility is really important to the Delphi team. That’s why monstrosities like nested WITH statements are still with us.
I just hope Barry and the rest of the team finds time to fill in holes for XE2. Specifically, it would be very nice to be able to use RTTI to access array properties. Being able to get at standalone functions (not methods of objects) would be nice too. That might require the addition of some sort of TRttiUnit class, which I definitely wouldn’t mind having either.
But that’s just an implementation detail. What I really want are array properties and standalone methods, and a public interface to the TMethodImplementation class. There’s a lot of potential in that class (introduced in the RTTI unit in Delphi XE) that’s unfortunately not available for public use. When I asked Allen Bauer about it, he said the team wasn’t sure they wanted to have to support it in its current form, but it might be made more available in a future release. I certainly hope so.
What do you think? Are there any other holes in RTTI that need filling in, and what would you do with them if you had them available?
*Sigh of relief* 🙂
Heh. Do you use the TypInfo structures in your code, Moritz?
Quite extensively, yes.
Personally I never use the stuff so what I’d love would be for a way to switch it off and not have my executables so much bigger than they need to be.
Try putting these two lines at the top of your DPR, before the USES clause:
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
This will make sure that no RTTI gets generated for your own code or any third-party libraries you use, unless they’re in a unit where RTTI generation is explicitly enabled. You can’t turn it off for the RTL or VCL, but that shouldn’t add very much to your size anyway.
That gives me a 20% reduction in image size. Thanks a bunch!
Now to go and read up on this so that I understand what it is doing……..
Pity, it means they’ll basically be going for two RTTI sets of information, with a “dead” legacy one being carried along as so much baggage. Delphi is already carrying so much baggage…
Hopefully there will be a switch to omit the old RTTI (and the old RTTI only).
That’s not how I read it, actually. Seems more like what he’s saying is that he’d like to change the format away from the current “dead legacy format,” but he can’t because that would break too much stuff. But if the new extended RTTI interface gets adopted by enough people, then it becomes more likely that sometime in the future they’ll be able to replace the underpinnings (TypInfo) with something more elegant. But that’s not going to happen anytime soon.
“Two RTTI sets of information” is a little over the top. The additional RTTI structures complement the “old” RTTI, and as I understand it, most information is not duplicated.
But we do have two RTTI APIs: the Beauty and the Beast. Unfortunately the former isn’t comprehensive yet.
i believe less backward compatibility would lead to a a better product mid-term. In other words dropping those “light weight” RTTI ideas because of compatibility concerns is a mistake. It should be done like they did with Unicode – full support and no “turn-off” compiler switch.
Hopefully the 64 bit compiler will not be throttled by these same concerns.