When designing an OO language, should I avoid write-only properties?

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?

Answer 1

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.

Answer 2

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"?

Answer 3

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.