'Why not just get rid of RTTI use for method invocation, and use plain good “interface” types instead?' you ask, commenting on a two and a half year old blog post that muses on the possibility of speeding up TRttiMethod.Invoke. 'When did you stop beating your wife?', Mason might reply in response...
On the substantive issue, one might argue that interfaces shouldn't be over-used either, given they encourage runtime querying ('as' casts/Supports calls) and therefore making assumptions that can't be checked by the compiler... which is part of the argument against RTTI abuse, is it not...?
The entire post was blabla imo. You did not show any concrete "abuses" of RTTI and the solution with using other patterns (and no, I am not reading through all the 20 links you put in there to probably find them).
Javier Hernández Erm, Delphi and the VCL are built on RTTI (metaclasses, DFM streaming). The 'extended' RTTI added later just brought the feature set up to contemporary standards, supplementing rather than replacing existing functionality. Also worth emphasising that Arnaud's own code relies on not just the original level of RTTI, but the Kylix/D6-era extensions too (http://bugs.freepascal.org/view.php?id=26774).
Chris Rolliston Of course, interface use should follow the SOLID principles, so that they are not abused either. You may use TVirtualInterface Horácio Filho to mock or remote an interface, adding some hidden code. But you should be able to use a direct execution of the interface, without any hidden code, and the program behavior should not change (LSP). In short, you may add some features via TVirtualInterface: e.g. our SOA framework allow remote execution of an interface, with proper logging in a log file or even in a log database, which is very convenient; or add some authorization step, for client/server safety. But the basic feature set (aka business logic, or "Design by Contract") should not be modified.
Javier Hernández Indeed. This was my last point in the blog article, about Microsoft going Native, and eventually reducing reflection scope in such .Net apps.
Stefan Glienke This is just blabla, you are right. I did not want to prove anything. I let it to some better computer rocket scientists. https://www.youtube.com/watch?v=GDVAHA0oyJU I just wanted to share some thoughts, on a Saturday afternoon. But it is coming from experiment, especially in C#: I have seen huge code base needed refactoring due to the "Native .Net" move. It was a server side SOA project, so here Native was a good move. Some business logic was handled by advanced reflection and run-time generated IR, and it was not allowed any more on this new compiler target. Rewriting in more classical OOP style did increase code readability and maintenance. There was less magic, eventually more lines of source code, but the result was somewhat cleaner. And we found some issues - as always, when you do code refactoring. My point was that RTTI is very good, and should be used when needed. But when you start using complex RTTI to implement the logic, just for laziness/magic/woweffect/icandothat, it may not be a so good ROI. Hidden code is hard to track. I gave a few examples in the blog post. This is IMHO where RTTI abuse starts.
I updated a little the blog post, to add an example (about logging), and make the point more explicit. This was not an anathema of RTTI. Just some thoughts that you should better not use RTTI and injection to implement the business logic. And that some "magic" using RTTI (e.g. logging via AOP) may not be the silver bullet you expected. Thanks for your feedback.
A. Bouchez I absolutly agree with you. For my business, maintainance of code is very importantant. Therefore "magic" RTTI code makes reading code harder. As one of the clean code principles: "Someone should be able to read the source code like a book and be able to figure out what it is doing without comments." I also use the compiler a lot to detect errors.
A. Bouchez I'm confused - TVirtualInterface is one of the features of extended RTTI to me, so if you're against 'RTTI' you're against that. 'Classic RTTI' in a Delphi sense = the TypInfo unit and metaclasses, 'D6-level RTTI' = the ObjAuto unit and $M+ supported for interfaces, 'extended RTTI' = the Rtti unit, inspectable metadata generated by default for public methods, etc.
Markus Ja 'I also use the compiler a lot to detect errors.' - you realise no one is arguing against that...? 'Therefore "magic" RTTI code makes reading code harder' - if you're using Delphi, you're likely using 'magic' RTTI code all the time, only implicitly.
Chris Rolliston TVirtualInterface is a "recent" addition. But AFAIK TVirtualInterface does NOT require the extended RTTI. Interface RTTI available since Delphi 6 is enough to define a TVirtualInterface. In mORMot, we created our own "virtual interface" (in a cleaner way than RTTI.pas IMHO), and it works seamlessly with Delphi 6/7... and later. Only FPC did lack this Delphi 6 level interface RTTI in its trunk - but they made a dedicated branch which supports it, which I hope would be merged soon in to FPC trunk. And I'm not against RTTI. On the contrary - we use plenty of it in mORMot. Please read my post. I'm against RTTI abuse, when you use RTTI to code your business logic, or use RTTI even if classic OOP would be enough. In short, my idea is: if you can do it with OOP, do not use RTTI.
Javier Hernández Er., no you can't. At best you are confusing the additional metadata produced by default since D2010 with 'RTTI' as such. RTTI is part of what made Delphi 'Delphi' way back in 1995 rather than Turbo Pascal for Windows 2.0.
A. Bouchez 'And I'm not against RTTI. On the contrary' - exactly. This whole discussion has been a bit silly, hasn't it? 'I'm against RTTI abuse' - curiously enough, neither myself nor Stefan disagree with such a notion. What we disagree with is an insinuation that Delphi's language capabilities should be stuck at what they were in 2002.
Chris Rolliston I did not make such an insinuation. On the contrary, I wrote I use the extended RTTI, if available - but was able to find workaround for older versions of Delphi. But I disagree with your insinuation ;) that Delphi's language capabilities of 2002 was not enough to write "modern" code, and apply SOLID or DDD principles. Everything needed was there, thanks to the great initial design of Delphi. Newest language evolutions, borrowed from C#/Java, were good, but IMHO not mandatory. And deprecating AnsiString or introducing ARC was IMHO a PITA. They came back from the "Delphi for .Net" for everyone. I'm happy I never used this target. Insinuation war of non said / extrapolated / imagined ideas did began. :D
DuckDuckDelphi is a very good example of utilizing Enhanced RTTI to help reducing a lot of code in situation where performance is not an issue - such as setting all UI controls to be readonly.
A. Bouchez Less code, while not reducing readable and performance. This is like asking JS coers: Why not just look through the DOM elements, without JQuery? :)
'Why not just get rid of RTTI use for method invocation, and use plain good “interface” types instead?' you ask, commenting on a two and a half year old blog post that muses on the possibility of speeding up TRttiMethod.Invoke. 'When did you stop beating your wife?', Mason might reply in response...
ReplyDeleteOn the substantive issue, one might argue that interfaces shouldn't be over-used either, given they encourage runtime querying ('as' casts/Supports calls) and therefore making assumptions that can't be checked by the compiler... which is part of the argument against RTTI abuse, is it not...?
The entire post was blabla imo. You did not show any concrete "abuses" of RTTI and the solution with using other patterns (and no, I am not reading through all the 20 links you put in there to probably find them).
ReplyDelete/sub
ReplyDeleteStefan Glienke too lazy to click few links? For me this post is good start point.
ReplyDeleteJavier Hernández Erm, Delphi and the VCL are built on RTTI (metaclasses, DFM streaming). The 'extended' RTTI added later just brought the feature set up to contemporary standards, supplementing rather than replacing existing functionality. Also worth emphasising that Arnaud's own code relies on not just the original level of RTTI, but the Kylix/D6-era extensions too (http://bugs.freepascal.org/view.php?id=26774).
ReplyDeleteI love TVirtualInterface <3
ReplyDeleteChris Rolliston Of course, interface use should follow the SOLID principles, so that they are not abused either.
ReplyDeleteYou may use TVirtualInterface Horácio Filho to mock or remote an interface, adding some hidden code. But you should be able to use a direct execution of the interface, without any hidden code, and the program behavior should not change (LSP).
In short, you may add some features via TVirtualInterface: e.g. our SOA framework allow remote execution of an interface, with proper logging in a log file or even in a log database, which is very convenient; or add some authorization step, for client/server safety. But the basic feature set (aka business logic, or "Design by Contract") should not be modified.
Javier Hernández Indeed. This was my last point in the blog article, about Microsoft going Native, and eventually reducing reflection scope in such .Net apps.
ReplyDeleteStefan Glienke This is just blabla, you are right. I did not want to prove anything. I let it to some better computer rocket scientists. https://www.youtube.com/watch?v=GDVAHA0oyJU
ReplyDeleteI just wanted to share some thoughts, on a Saturday afternoon. But it is coming from experiment, especially in C#: I have seen huge code base needed refactoring due to the "Native .Net" move. It was a server side SOA project, so here Native was a good move. Some business logic was handled by advanced reflection and run-time generated IR, and it was not allowed any more on this new compiler target. Rewriting in more classical OOP style did increase code readability and maintenance. There was less magic, eventually more lines of source code, but the result was somewhat cleaner. And we found some issues - as always, when you do code refactoring.
My point was that RTTI is very good, and should be used when needed. But when you start using complex RTTI to implement the logic, just for laziness/magic/woweffect/icandothat, it may not be a so good ROI. Hidden code is hard to track. I gave a few examples in the blog post. This is IMHO where RTTI abuse starts.
I updated a little the blog post, to add an example (about logging), and make the point more explicit.
ReplyDeleteThis was not an anathema of RTTI. Just some thoughts that you should better not use RTTI and injection to implement the business logic. And that some "magic" using RTTI (e.g. logging via AOP) may not be the silver bullet you expected.
Thanks for your feedback.
A. Bouchez
ReplyDeleteI absolutly agree with you. For my business, maintainance of code is very importantant. Therefore "magic" RTTI code makes reading code harder. As one of the clean code principles: "Someone should be able to read the source code like a book and be able to figure out what it is doing without comments."
I also use the compiler a lot to detect errors.
A. Bouchez I'm confused - TVirtualInterface is one of the features of extended RTTI to me, so if you're against 'RTTI' you're against that. 'Classic RTTI' in a Delphi sense = the TypInfo unit and metaclasses, 'D6-level RTTI' = the ObjAuto unit and $M+ supported for interfaces, 'extended RTTI' = the Rtti unit, inspectable metadata generated by default for public methods, etc.
ReplyDeleteMarkus Ja 'I also use the compiler a lot to detect errors.' - you realise no one is arguing against that...? 'Therefore "magic" RTTI code makes reading code harder' - if you're using Delphi, you're likely using 'magic' RTTI code all the time, only implicitly.
Chris Rolliston TVirtualInterface is a "recent" addition. But AFAIK TVirtualInterface does NOT require the extended RTTI. Interface RTTI available since Delphi 6 is enough to define a TVirtualInterface. In mORMot, we created our own "virtual interface" (in a cleaner way than RTTI.pas IMHO), and it works seamlessly with Delphi 6/7... and later.
ReplyDeleteOnly FPC did lack this Delphi 6 level interface RTTI in its trunk - but they made a dedicated branch which supports it, which I hope would be merged soon in to FPC trunk.
And I'm not against RTTI. On the contrary - we use plenty of it in mORMot. Please read my post. I'm against RTTI abuse, when you use RTTI to code your business logic, or use RTTI even if classic OOP would be enough. In short, my idea is: if you can do it with OOP, do not use RTTI.
Javier Hernández Er., no you can't. At best you are confusing the additional metadata produced by default since D2010 with 'RTTI' as such. RTTI is part of what made Delphi 'Delphi' way back in 1995 rather than Turbo Pascal for Windows 2.0.
ReplyDeleteA. Bouchez 'And I'm not against RTTI. On the contrary' - exactly. This whole discussion has been a bit silly, hasn't it? 'I'm against RTTI abuse' - curiously enough, neither myself nor Stefan disagree with such a notion. What we disagree with is an insinuation that Delphi's language capabilities should be stuck at what they were in 2002.
ReplyDeleteChris Rolliston I did not make such an insinuation. On the contrary, I wrote I use the extended RTTI, if available - but was able to find workaround for older versions of Delphi.
ReplyDeleteBut I disagree with your insinuation ;) that Delphi's language capabilities of 2002 was not enough to write "modern" code, and apply SOLID or DDD principles. Everything needed was there, thanks to the great initial design of Delphi. Newest language evolutions, borrowed from C#/Java, were good, but IMHO not mandatory. And deprecating AnsiString or introducing ARC was IMHO a PITA. They came back from the "Delphi for .Net" for everyone. I'm happy I never used this target.
Insinuation war of non said / extrapolated / imagined ideas did began. :D
DuckDuckDelphi is a very good example of utilizing Enhanced RTTI to help reducing a lot of code in situation where performance is not an issue - such as setting all UI controls to be readonly.
ReplyDeleteEdwin Yip Why not just use a recursive loop setting the Enabled property, without RTTI?
ReplyDeleteA. Bouchez Less code, while not reducing readable and performance. This is like asking JS coers: Why not just look through the DOM elements, without JQuery? :)
ReplyDeleteEdwin Yip You are indeed comparing apples and oranges.
ReplyDelete