Delphi Event-based and Asynchronous Programming I just had to do it... Go with the flow! It's the Black Friday / Cyber Monday "season", so I had to rush the book offer The book was actually scheduled for release in early December, but then the Black Friday deals started popping up all over the place... pressure was building... and I finally caved in! I cut the darn thing in two, and decided to offer Part I at a discount, and will give Part II for free to all Buyers. Not really a 97% BF discount but hey... Junior is still studying, and we still have to pay the bills (Corona doesn't help, either)! So, here it is! I hope you'll like it like you did Delphi Memory Management! https://dalija.prasnikar.info/delphiebap/index.html Event-based programming is everywhere. Nowadays, you can hardly write any kind of application without leaning on events and messages. This simple, yet extremely powerful mechanism is also the cornerstone of asynchronous and multithreaded prog
Here's some questions in advance for you (which I'll have to catch on the replay (hint, hint) due to timezones).
ReplyDeleteWhat's your thoughts on The Wiert Corner's aversion to using AfterConstruction? (see his blog post 2021/03/23)
For method parameters what data types do you make const rather than leaving them as a ordinary value parameter? These days I'm using const routinely for strings, interfaces and anonymous methods. I had started doing it for TObject descendants when there was the possibility of my code being run under ARC but I've since removed the consts from those.
I forgot about records. I routinely const those as well.
DeleteAfterConstruction is safe and IMO not used enough. Modifying base class and adding additional virtual DoCreate method is fine, too, if you have base class and you have reasons for not making constructor virtual. But, I would still prefer using it more for configuration than for constructing instances - in other words for final setup after you know all pieces of the object are fully constructed, but that also depends on particular use case. If you need speed, then using AfterConstruction rather than adding new virtual methods is faster.
DeleteThe only part where you need to be careful with AfterConstruction is with reference counted classes and triggering reference counting inside AfterConstruction after you called inherited method - that will cause self destruction of the object. See: https://dalijap.blogspot.com/2019/12/self-destructing-object-instance.html
Also, regardless of the exceptions raised in AfterConstruction, full cleanup will run including BeforeDestruction and Destroy. So that part was not fully correct at least not for newer versions. In Delphi 7 BeforeDestruction is not called, but destructor is. In XE4+ both BeforeDestruction and Destroy are called.
Anyway, since destructor must be able to handle cleanup of partially constructed objects anyway, BeforeDestruction is necessary only seldom, as anything created there can be cleaned up in Destroy.
For parameters, I am following same logic you do. I also use it for larger records if I don't need to modify it - it allows compiler to optimize and avoid copying the whole record.
I couldn't help myself answering your questions here... but I will mention that topic on the webinar, too :)
Delete