The black hole
-
"Lasciate ogni speranza o voi ch'entrate" Dante Alighieri
private double m_EdgeDim; public double EdgeDim { set { m_EdgeDim = value; } }Don't you really want to see what you have put?**************************** Strong congruence for strong people; with a compatible behaviour. For a semantical way of life.
See also this message from April[^]
-
See also this message from April[^]
-
"Lasciate ogni speranza o voi ch'entrate" Dante Alighieri
private double m_EdgeDim; public double EdgeDim { set { m_EdgeDim = value; } }Don't you really want to see what you have put?**************************** Strong congruence for strong people; with a compatible behaviour. For a semantical way of life.
I understand the point of a write-only property, but I don't like the idea of really using it. It's only going to confuse you or anyone else working with the code. After all, the only one who really isn't supposed to know the value of the property is the user, so as long as it's not displayed to the user, it should be fine. Using a write-only property will only make debugging and refactoring harder. In my opinion, this is a bad practice.
-
I understand the point of a write-only property, but I don't like the idea of really using it. It's only going to confuse you or anyone else working with the code. After all, the only one who really isn't supposed to know the value of the property is the user, so as long as it's not displayed to the user, it should be fine. Using a write-only property will only make debugging and refactoring harder. In my opinion, this is a bad practice.
I am writing the code for my first (proper) CP article and I did have one write only property. I have a webcam class that I want to control to a T (via a VisionController class). On the webcam wizard the user selects the device and the wizard puts it in the class. I don't want ANY other portion of code interacting with it: so once the class is in I can get to it. It forces me to create proper interfaces, and now that I have completed them I put the get {} in there ;).
-
I understand the point of a write-only property, but I don't like the idea of really using it. It's only going to confuse you or anyone else working with the code. After all, the only one who really isn't supposed to know the value of the property is the user, so as long as it's not displayed to the user, it should be fine. Using a write-only property will only make debugging and refactoring harder. In my opinion, this is a bad practice.
Megidolaon wrote:
Using a write-only property will only make debugging and refactoring harder.
Why?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
I understand the point of a write-only property, but I don't like the idea of really using it. It's only going to confuse you or anyone else working with the code. After all, the only one who really isn't supposed to know the value of the property is the user, so as long as it's not displayed to the user, it should be fine. Using a write-only property will only make debugging and refactoring harder. In my opinion, this is a bad practice.
I have several classes I use for instrumentation control and port access. I use the write only property as a means of passing instructions to the remote devices (reads easier in my opinion) and this suggests that the property value is not stored just passed along. Ex: remoteDevice.IO.Send = "SETVOLT 25"; If I wanted to set some kind of parameter value that is stored in the class but should not be read I would use the following method: serializer.SetInitialValue(103);
-
I have several classes I use for instrumentation control and port access. I use the write only property as a means of passing instructions to the remote devices (reads easier in my opinion) and this suggests that the property value is not stored just passed along. Ex: remoteDevice.IO.Send = "SETVOLT 25"; If I wanted to set some kind of parameter value that is stored in the class but should not be read I would use the following method: serializer.SetInitialValue(103);
Well I consider those to be backward, but it's really a matter of style.
-
I am writing the code for my first (proper) CP article and I did have one write only property. I have a webcam class that I want to control to a T (via a VisionController class). On the webcam wizard the user selects the device and the wizard puts it in the class. I don't want ANY other portion of code interacting with it: so once the class is in I can get to it. It forces me to create proper interfaces, and now that I have completed them I put the get {} in there ;).
What about putting it in the constructor? Or should it be modified? J
James Simpson Web Developer imebgo@hotmail.com P S - This is what part of the alphabet would look like if Q and R were eliminated
Mitch Hedberg -
"Lasciate ogni speranza o voi ch'entrate" Dante Alighieri
private double m_EdgeDim; public double EdgeDim { set { m_EdgeDim = value; } }Don't you really want to see what you have put?**************************** Strong congruence for strong people; with a compatible behaviour. For a semantical way of life.
Don't you know about the black hole design pattern?? Looks like this..
public class BlackHole
{
private T _hole;
public T Hole {
set {
try {
this._hole = value;
}
catch {
throw new BlackHoleException();
}
}
}
} -
What about putting it in the constructor? Or should it be modified? J
James Simpson Web Developer imebgo@hotmail.com P S - This is what part of the alphabet would look like if Q and R were eliminated
Mitch HedbergYeah I thought about putting it in the CTor, but the thing is that a wbcam wizard updates it, I am thinking I really should make a set method because it has a few side effects (rule of properties: if it doesn't have side effects make it a property, if it does make it a method).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Megidolaon wrote:
Using a write-only property will only make debugging and refactoring harder.
Why?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain ClarkeIMO, it's a bit of a hassle because you can only see the values while debugging and having them display in the Watch window. A examples was provided where it might be a good idea to use a write only properties but I simply don't like the idea. I haven't gotten into the situation where I'd need a write only property and if I ever got into such a situation, I'd re-think my design.
-
Megidolaon wrote:
Using a write-only property will only make debugging and refactoring harder.
Why?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain ClarkeThe only good example of a write-only property I've come across is with authentication. A class representing a user might have a username and a password. The password is required for authentication, but should not be generally accessible to the rest of an application. If you have a code-base which supports third-party plug-in authoring then you may not be able to guarantee all plug-in code is safe / responsible... In this case a write-only property for the class is a good plan if the user object is then shared. Otherwise I would tend to agree with the use of a setter method... Might be a background thing, though :cool: - I know a lot of the VB folks like properties for class field setters/getters.
AJ
-
IMO, it's a bit of a hassle because you can only see the values while debugging and having them display in the Watch window. A examples was provided where it might be a good idea to use a write only properties but I simply don't like the idea. I haven't gotten into the situation where I'd need a write only property and if I ever got into such a situation, I'd re-think my design.
Megidolaon wrote:
and if I ever got into such a situation, I'd re-think my design.
Absolutely, if you can't read it, it's not a property.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
"Lasciate ogni speranza o voi ch'entrate" Dante Alighieri
private double m_EdgeDim; public double EdgeDim { set { m_EdgeDim = value; } }Don't you really want to see what you have put?**************************** Strong congruence for strong people; with a compatible behaviour. For a semantical way of life.
Marcello Faga wrote:
Don't you really want to see what you have put?
Not really, it could be a writeonly type of scenario.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
"Lasciate ogni speranza o voi ch'entrate" Dante Alighieri
private double m_EdgeDim; public double EdgeDim { set { m_EdgeDim = value; } }Don't you really want to see what you have put?**************************** Strong congruence for strong people; with a compatible behaviour. For a semantical way of life.