Why aren't readonly and writeonly C++ Keywords?

Started by
34 comments, last by haro 20 years, 9 months ago
Thanks for all the feedback. Suprisingly the most common reason people seem to be against the concept is because of an affinity to OO and the possibility that it does not fit completely within the paradigm.. which is encouraging. Without any serious arguments against them, the concept of readonly/writeonly become that much more attractive.

Very interesting reading the papers Fruny, though proposals tend to be dryer than the Sahara. I definitely found this paper interesting, which approaches the same concept in a different manner. I suppose its only a matter of time before something along these lines is implemented.. which also 'answers' the thread. I originally thought I was a minority in desiring declared read/write modifiers, I was wrong.


[edited by - haro on July 8, 2003 7:08:55 PM]
Advertisement
I like the idea of properties where you can do 1 of 2 things on read and write: pass the operation directly to a certain class variable (effectively making it public for read or write, if you want to allow only one operation) or call a function (as in the python example, so you can do any processing on the input/output that you want to). It makes code much shorter and more readable imo, though it can obviously lead to some possibly confusing situations (like having a property named z that returns the x member when read and modifies the y member when written to so that (a.z = 5) == 5 can be false for no apparent reason), but those kinds of situations already exist and are abused every day.

As for the particle/wind example - I would say make wind a friend of particle, or make a ParticleSystem class and have it be a friend of particle. The ParticleSystem class could apply any forces, spawn new particles etc, and the particle itself just holds its position, velocity, age, lifetime, sprite ID, etc.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
I remember reading an article a while ago that said something along the lines of "if there''s any get/set functions in your program, it''s not OO"

Not sure I agree with that completely but it does raise a lot of interesting design questions

"That''s not a bug, it''s a feature!"
--me
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
quote:Original post by ChaosEngine
I remember reading an article a while ago that said something along the lines of "if there''s any get/set functions in your program, it''s not OO"


Do you have any idea what the article proposed as an alternative to get/set functions? I mean if they aren''t OO, then what is an example of something that is OO?

Personally, I don''t see how get/set functions affect whether or not your design is OO.
quote:Original post by SpaceRogue
quote:Original post by ChaosEngine
I remember reading an article a while ago that said something along the lines of "if there''s any get/set functions in your program, it''s not OO"


Do you have any idea what the article proposed as an alternative to get/set functions? I mean if they aren''t OO, then what is an example of something that is OO?

Personally, I don''t see how get/set functions affect whether or not your design is OO.


Ask yourself "If I didn''t have that variable, would this function/method/message (terminology is different between languages) still exist in this class?". If the answer is "no", then it''s not OO. Basically, are you allowing access to the variable, or are you allowing access to a property of the class (which, in your implementation, happens to have a direct mapping to an instance/member variable)?
quote:Original post by ChaosEngine
I remember reading an article a while ago that said something along the lines of "if there''s any get/set functions in your program, it''s not OO"

Bollocks to OO! Its just bad design (in general).

This topic is closed to new replies.

Advertisement