Oh no, not again....
-
Another two (three?) hours spent on this kind of typo:
public int LoadedSampleCount
{
get { return (int)GetValue(LoadedSampleCountProperty); }
set { SetValue(LoadedSampleCountProperty, value); }
}
public static readonly DependencyProperty LoadedSampleCountProperty =
DependencyProperty.Register("LoadedSampleCount", typeof(int), typeof(TreeWindowVM SampleSetLoaderVM), new PropertyMetadata(0));This is a result of a "GUI refactoring" -- moving parts of code to an user control. And forgetting to set an owner of a dependency property to a new model view again. Awww... :mad::mad:
Greetings - Jacek
-
Another two (three?) hours spent on this kind of typo:
public int LoadedSampleCount
{
get { return (int)GetValue(LoadedSampleCountProperty); }
set { SetValue(LoadedSampleCountProperty, value); }
}
public static readonly DependencyProperty LoadedSampleCountProperty =
DependencyProperty.Register("LoadedSampleCount", typeof(int), typeof(TreeWindowVM SampleSetLoaderVM), new PropertyMetadata(0));This is a result of a "GUI refactoring" -- moving parts of code to an user control. And forgetting to set an owner of a dependency property to a new model view again. Awww... :mad::mad:
Greetings - Jacek
Seems like some people like to make things in C# more complex than they need to be. Makes it much easier to generate bugs. They must have a great desire to become an entomologist. One of the things that confused me was that people were changing readonly objects. Then the oh, duh, moment. the address and definition of the object can't change. Internal changes don't count as changing the object.
-
Seems like some people like to make things in C# more complex than they need to be. Makes it much easier to generate bugs. They must have a great desire to become an entomologist. One of the things that confused me was that people were changing readonly objects. Then the oh, duh, moment. the address and definition of the object can't change. Internal changes don't count as changing the object.
-
Seems like some people like to make things in C# more complex than they need to be. Makes it much easier to generate bugs. They must have a great desire to become an entomologist. One of the things that confused me was that people were changing readonly objects. Then the oh, duh, moment. the address and definition of the object can't change. Internal changes don't count as changing the object.
Sorry for late comment... but I have to ask: You think "readonly" should mean the same like "const"? Did you never had the need to "calculate" a later constant value? I like the "readonly" construct (keyword) and think it's a good thing to have. (and you can only reset in in constructors and not everywhere) To the related topic you mentioned - that changing the through a readonly variable represented object doesn't count as changing the variable, and isn't forbidden -> it's completly clear for me that a pointer-variable change means to change it's content - the address it is representing not the object it is pointing to. That's also true for const pointers in C++ and all other languages I know - have you seen a language where a constant pointer means that the pointed object is immutable?
-
Sorry for late comment... but I have to ask: You think "readonly" should mean the same like "const"? Did you never had the need to "calculate" a later constant value? I like the "readonly" construct (keyword) and think it's a good thing to have. (and you can only reset in in constructors and not everywhere) To the related topic you mentioned - that changing the through a readonly variable represented object doesn't count as changing the variable, and isn't forbidden -> it's completly clear for me that a pointer-variable change means to change it's content - the address it is representing not the object it is pointing to. That's also true for const pointers in C++ and all other languages I know - have you seen a language where a constant pointer means that the pointed object is immutable?
johannesnestler wrote:
I have to ask: You think "readonly" should mean the same like "const"?
Not really, I don't recall talking with the instructor about either const or readonly. And I didn't read anything in the books I'd bought for the training. I just recall seeing it for the first time on the job and my amazement that the values in the readonly object were being changed and the compiler wasn't complaining. Then an "Oh, duh" moment. You can't change the instance, but you can change the contents of the instance. This code is totally legal:
public class vals { public int age; public DateTime date; } class x { public readonly vals val = new vals(); } static void Main(string\[\] args) { x val = new x(); val.val.age = 20; val.val.date = DateTime.Now;...
const has it's own peculiarities, basically it supports value types. When you read the documentation it says the only non-value type is string. I was taught that string was also a value type. I haven't read any documentation (other than const) that contradicts string is a value type. I got an eye opener several years ago when I read that you shouldn't send a string to unmanaged C++ code. Before that, I was totally confused by the statement that strings were IMMUTABLE. I can change the value of the string whenever I want! After I read that article I understood what was meant by that and it makes me believe that you can change a const string variable's value by passing it to that C++ code I mentioned. Much later I learned about Intern and IsInterned. Because I am not dedicated to this language I don't consider myself near an expert in C#. More knowledgeable than some C# programmers, most dedicated C# developers know more than me.
-
johannesnestler wrote:
I have to ask: You think "readonly" should mean the same like "const"?
Not really, I don't recall talking with the instructor about either const or readonly. And I didn't read anything in the books I'd bought for the training. I just recall seeing it for the first time on the job and my amazement that the values in the readonly object were being changed and the compiler wasn't complaining. Then an "Oh, duh" moment. You can't change the instance, but you can change the contents of the instance. This code is totally legal:
public class vals { public int age; public DateTime date; } class x { public readonly vals val = new vals(); } static void Main(string\[\] args) { x val = new x(); val.val.age = 20; val.val.date = DateTime.Now;...
const has it's own peculiarities, basically it supports value types. When you read the documentation it says the only non-value type is string. I was taught that string was also a value type. I haven't read any documentation (other than const) that contradicts string is a value type. I got an eye opener several years ago when I read that you shouldn't send a string to unmanaged C++ code. Before that, I was totally confused by the statement that strings were IMMUTABLE. I can change the value of the string whenever I want! After I read that article I understood what was meant by that and it makes me believe that you can change a const string variable's value by passing it to that C++ code I mentioned. Much later I learned about Intern and IsInterned. Because I am not dedicated to this language I don't consider myself near an expert in C#. More knowledgeable than some C# programmers, most dedicated C# developers know more than me.
I think the idea for the readonly keyword in C# was stolen from JAVA (final keyword). And solves the problem I mentioned. (What to do if a later constant value must be calculated?) In the example you have given, you can see what I mean: What did you declare as readonly? The age or date properties? -> No, You declared the val variable of type vals as readonly. Because vals is a reference type (you created it with the class keyword) the variable val is now holding the address of the new vals instance on the heap. - so val is a pointer. This is the variable that is immutable, you can not change this pointer (the address it is holding) in an other way but the rules for readonly keyword usage are dictating. So if you don't know any language where a "constant pointer" means the object pointed to is immutable (nor do I), how would you expect it to behave in an imaginary language? What if the pointed object is holding a lot of other references (pointers). Should they be then immutable too? I think if you go that thought to the end, you will come to the conclusion that the current behaviour is the only logical consistent one - please correct me if I'm wrong... greetings from Austria :rose:
-
I think the idea for the readonly keyword in C# was stolen from JAVA (final keyword). And solves the problem I mentioned. (What to do if a later constant value must be calculated?) In the example you have given, you can see what I mean: What did you declare as readonly? The age or date properties? -> No, You declared the val variable of type vals as readonly. Because vals is a reference type (you created it with the class keyword) the variable val is now holding the address of the new vals instance on the heap. - so val is a pointer. This is the variable that is immutable, you can not change this pointer (the address it is holding) in an other way but the rules for readonly keyword usage are dictating. So if you don't know any language where a "constant pointer" means the object pointed to is immutable (nor do I), how would you expect it to behave in an imaginary language? What if the pointed object is holding a lot of other references (pointers). Should they be then immutable too? I think if you go that thought to the end, you will come to the conclusion that the current behaviour is the only logical consistent one - please correct me if I'm wrong... greetings from Austria :rose:
The only thing wrong with the way readonly works is my initial impression of it when I first encountered it. I got that impression before I read any documentation on the property. First impressions can be exactly right, but they are usually wrong. As soon as I got it through my head that the object I was looking at was a reference type it came clear how readonly worked. Doesn't even have to be a reference type, everything has a reference location in memory, that's how const can work as well.