Leaderboard

Different languages have different set of features and also differ in implementations of those features. Properties in general are a tool that provides additional level of abstraction around encapsulation and enables future implementation changes while preserving stable public API. Some of the benefits are more visible in some languages than the others. For instance, if you have public field Name and you want to add some code around retrieving that field is easy to do in Delphi. You can rename field and move it to private section and declare public function Name to retrieve it. I Java, you cannot do such thing because calling method must include brackets. This requires refactoring all code that uses such field. If you want to add setter, you will break the code in any language. This is where using properties helps with encapsulation. They hide unnecessary implementation details and give implementing class to ability to change those without breaking user code. You can start with simple field backed property, which from performance aspect is no different than public field and you can add getters and setters as needed without breaking code. Without properties, you can also maintain stable API, but the cost is having getters and setters for everything and paying the price in performance. No matter how small it is, eventually it can add up. Additionally, code with simple assignment is easier to read than setter method. There are some parts of general properties functionality that Delphi does not implement, like different access levels for reading and writing, or some additional ceremony when declaring properties, especially in interfaces. Some of those could be improved to make properties more flexible, but lacking them is poor argument against using properties. In situations where you really need some functionality properties don't provide, you can use other ways to achieve what you need, but not using properties everywhere else because you cannot do something in rare occasions is also not very convincing argument. Arguments around name refactoring are not very convincing either. They compare name refactoring, where there is a bit more renaming in declaration. Now, compare that single place where you need to make additional rename, to refactoring all code in case where you need to replace public fields with accessor methods. When it comes to extra declaration code needed for properties with accessor methods comparing to only having accessor methods, think how much unnecessary getters and setter methods you need to write in cases where you could use field backed property declaration. Overall using properties results with cleaner code and having more functionality than you can have with simple fields or just accessor methods. The little bit of ceremony around the declaration is price I am more than willing to pay, to get all other benefits.

That has never been necessary using MMX. Renaming the property automatically renames the field, getter, setter and optionally all references to the property in the current unit. Also related to MMX: Using read/write properties allows to make use of the reverse assignment tool.

Other advantages: Properties can be read-only. Since you can opt to have methods for the setter and getter of a property, you also have a place to monitor the activity of the said property - with a breakpoint that simply counts accesses, a method that logs the accesses, or an actual breakpoint Using the get method, a property can allow for lazy instance generation, so that if it is never used, the connected instance is never instantiated Using the set method - the validity of a property value can be decided on assignment, without needing that validation to be spread around on the calling code

I'm OK, guys, thanks for asking. Not Corona, but I've spent some time in the hospital nonetheless.

It's also interesting in what timezone the working hours are.

they have index you can inherit the accessors they have nice RTTI support, can be decorated the h*ll are you talking about, how should be a GetThis() more verbose about its implementation as a property?

My first "serious" languages were C++, then Java. They both do not have properties. Maybe I'm biased. My brutally honest opinion: No one needs properties, especially with how limited they are in Delphi. Disadvantages include You cannot fine-grain access (public read access, protected write access) Delphi's code completion does not even show you if a property is writeable or not. You cannot pass them by reference (var or out parameters) like you can with fields It hides performance impacts. Is it just syntax sugar for directly reading a field? Or is it using a getter method that first locks something, then accesses a resource, calculates it, and then finally returns it? When performance matters, I do not know. I have to look at the implementation. They can do nothing a regular getter/setter cannot. Which you will have to write anyway. Tl;dr: Lose some advantages of using fields, lose some advantages of using getters/setters. Gain nothing, except saving three letters for "get" or "set".

What is the working language for communications in your company? English, Russian?

I recently stumbled upon QT API where there's no properties and it looks REALLY awful. Instead of Class.FooProp they have Class.getFooProp and Class.setFooProp. API size is doubled with no real necessity. So properties are awesome. Drawback is that they sometimes do too good job hiding implementation details so a user utilizes them with huge perf impact (Memo.Text := Memo.Text + s - this looks too simple but contains pretty heavy code underneath). Moreover, mechanism of published properties allows automatic (de)serialization - DFM, JSON, XML to and from object could only be done via properties

Notepad++ next 🙂