Delphi Programming Tips & Tricks

In Delphi, properties can be backed by simple fields, but they can also have getter and setter functions that can be vital to the proper functioning of a class. They can contain additional initialization code, protect the consistency of the object's data, prevent invalid input... Photo: Gary Todd from Xinzheng, China, PDM-owner, via Wikimedia Commons, https://commons.wikimedia.org/wiki/File:Colosseum_(48412957912).jpg As you might guess, field-based serialization does not call the appropriate getters and setters, and can cause runtime malfunctions. On the other hand, property-based serialization calls getters and setters if any exist. This is another thing to consider when using REST.Json , which uses field serialization instead of property serialization. REST.JSON ignores property setters https://quality.embarcadero.com/browse/RSP-26262

Did you miss the TCoffeeAndCode session on "All about threading and concurrency"?  The webinar replay is now available!  Hosted by Jim McKeeth and his guests: Frank Lauter, Primož Gabrijelčič, Olaf Monien, Kelver Merlotti and Dalija Prasnikar.   https://www.youtube.com/watch?v=KosLWa08X4Q

In case you missed the live session, webinar replay Mastering Delphi Memory Management where I am answering your questions about memory management is available on YouTube.  Book intro by Neven Prasnikar Jr. followed by a recording of live Q&A chat hosted by Jim McKeeth. Webinar replay: https://www.youtube.com/watch?v=_0_cUcygmLU Book info: https://dalija.prasnikar.info/delphimm Thank you all for joining live session and watching!

In the previous article, we learned that native Delphi serialization is based around published properties, and that other kinds of serialization, like field-based serialization, don't fit well with the Delphi model. Photo: Gary Todd from Xinzheng, China, PDM-owner, via Wikimedia Commons, https://commons.wikimedia.org/wiki/File:Colosseum_(48412957912).jpg We have also learned that property-based serialization has some limitations and that it does not have out-of-the-box support for the serialization of records, arrays, or indexed properties, and you can only serialize collections defined as TCollection , whose items are descendants of TCollectionItem . While serialization as a concept is widely used to convert any kind of objects into various storage formats, the main purpose of the Delphi serialization model being built on top of published properties and descendants of TComponent was to serialize the user interface and data modules. This is where the original type limitati

Join me this Thursday, Apr 22, 2021 5:00 PM - 6:00 PM CEST for a live Q/A session about Delphi memory management. See you!  Register for webinar: https://register.gotowebinar.com/register/474961949731996432 Book information: https://dalija.prasnikar.info/delphimm  

While different OOP languages share some common principles and many coding patterns will be the same or at least fairly similar, there are also some significant differences that can make some commonly used patterns from one language quite unsuitable in another—and if used, such patterns can cause a lot of trouble. Photo: Gary Todd from Xinzheng, China, PDM-owner, via Wikimedia Commons, https://commons.wikimedia.org/wiki/File:Colosseum_(48412957912).jpg One such pattern can be found in their serialization approaches. In Java, object serialization is performed on fields. In Delphi, the convention is to serialize published properties. That is also the original purpose of the published visibility specifier. Delphi also supports defining custom properties in TPersistent descendants, via DefineProperties method. When it comes to what kind of properties Delphi can serialize out of the box, there are some limitations, so you cannot serialize records, arrays, or indexed properties, and