When designing an OO language, should I avoid write-only properties?
-
11-02-2021 - |
Question
I am designing an object-oriented programming language for the purpose of learning. The language has properties, like this:
Class Fruit:
Property ReadWrite Float weight
Property WriteOnly Integer someWriteOnlyProperty # <-- avoid?
Should I add the option for write-only properties or will this only lead to bad design decisions in programs using this language?
Solution
By all means design write-only properties - just be aware they are of limited use (if you are only going to write to it and never expose it, why have a property?).
Might as well use a simple method instead. This will reduce any confusion of those using your code.
Java and .NET do have write only properties, so there are precedents.
OTHER TIPS
A Write-Only property doesn't make a sense to me. Read-Only properties for information purposes are very helpful, but what is a concrete secenario for "I give you an information, but I would never be able to find out what you're knowing"?
Other OO languages allow this. For example in Java you can create a private variable and add a method that lets you change the variable, but not read it. Your approach is more along the lines of Microsoft, explicitly creating "properties", but I don't see why this would be a problem. If you design an OO language to prevent all bad design decisions then your language won't do anything except print "DENIED" and then shut down.