0

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?

  • I think the idea of properties the way it is implemented in most OOP languages today is pure evil and should be avoided. – MK. Oct 24 '11 at 12:35
  • What for writeonly properties are? – Ankur Oct 24 '11 at 12:36
  • 3
    @MK. - Can you expand on that? Why do you think it is "pure evil"? – Oded Oct 24 '11 at 12:36
  • 1
    Because I do not like the syntactic sugar which takes information from the reader. When looking at a line of code I want to know whether there is only a property value being changed or if there is a method being invoked. – MK. Oct 24 '11 at 12:43
  • @MK. properties are implemented using methods here (the programmer can change the implementation of their setters and getters), and method calls and properties set/get have a separate syntax (`.` for properties, `->` for methods). I don't think the syntactic sugar will be a problem in this case, but for other languages I completely agree with you. –  Oct 24 '11 at 12:44
  • @WTP so what exactly is an advantage of properties over getter/setter methods? – MK. Oct 24 '11 at 12:47
  • @MK. the compiler can automatically generate setters and getters from properties if you don't write them manually. –  Oct 24 '11 at 12:47
  • @MK. See [What is the point of properties?](http://programmers.stackexchange.com/q/62383/7043). My points in a nutshell: Whether a line of code uses a plain attribute, a setter or a property under the hood doesn't matter if the code is clear and well-written. Decent properties, like getters/setters, don't do anything fancy that would require awareness. And before you complain that this requires well-written code... if the code isn't well-written, you're screwed anyway (people who write properties with unexpected effects would just as well stick those effects into getter/setter methods). –  Oct 24 '11 at 13:57
  • possible duplicate of [Do write-only properties have practical applications?](http://stackoverflow.com/questions/2213879/do-write-only-properties-have-practical-applications) – nawfal Apr 19 '13 at 18:59

3 Answers3

3

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.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 1
    What benefit can be derived from a write-only property? – DJ Quimby Oct 24 '11 at 12:43
  • @DJQuimby - It can help enforce encapsulation. See this: http://stackoverflow.com/questions/2213879/do-write-only-properties-have-practical-applications – Oded Oct 24 '11 at 12:44
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"?

Fischermaen
  • 12,238
  • 2
  • 39
  • 56
  • 1
    I think an example would be changing a password. You can't see the original value, only change it. – dnuttle Oct 24 '11 at 12:38
  • That is not a real example. If you can set a password you have that password as long as your program is running. Only the next time your program is started it has "forgotten the password and can never ask for it". mmmpf – Fischermaen Oct 24 '11 at 12:40
  • http://stackoverflow.com/questions/2213879/do-write-only-properties-have-practical-applications – Oded Oct 24 '11 at 12:41
1

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.

dnuttle
  • 3,810
  • 2
  • 19
  • 19