From: K Viltersten on 5 Oct 2009 14:53 >> Regard the following code. >> >> ... >> this.SomeProperty = (bool)thing; >> ... >> >> Suppose that we expect a co-worker to change >> the type of SomeProperty and thing at any time. However, he/she won't >> change the cast type. > > Your code example is difficult to follow. Could you elaborate which part is diffucult to follow? I'm looking for a good way to typecast an object to a corresponding type of the variable i'm going to assign it to. Is it (easily) doable? > But, as a general rule, one should not make any significant > change to any class member without searching for and inspecting > _every_ use of that class member to ensure the change isn't going > to break other code. I agree with you entirely. However, that doesn't answer my question. > I don't understand why one would be working in a development > environment where it's acceptable to change the type of a property, > but not to fix all assignments to that property to ensure that the type > remains correct. Seems like a recipe for bugs to me. Once again, i do agree with you. I'm not looking for a discussion whether it's bad or error prone way to do things. We're already agreed on that. I'm looking for a good way to deal with the situation, though, once i've found myself facing it. -- Regards Konrad Viltersten -------------------------------- May all spammers die an agonizing death; have no burial places; their souls be chased by demons in Gehenna from one room to another for all eternity and beyond.
From: Harlan Messinger on 5 Oct 2009 15:50 K Viltersten wrote: >>> Regard the following code. >>> >>> ... >>> this.SomeProperty = (bool)thing; >>> ... >>> >>> Suppose that we expect a co-worker to change >>> the type of SomeProperty and thing at any time. However, he/she >>> won't change the cast type. >> >> Your code example is difficult to follow. > > Could you elaborate which part is diffucult to follow? > > I'm looking for a good way to typecast an object to a corresponding > type of the variable i'm going to assign it to. Is it (easily) doable? If the compiler is going to know to just cast to whatever type the receiving variable is, then why would there be explicit casting in the first place? If your coworker is changing the type of SomeProperty, then he'd better know that it means he's changed its use and purpose and he'd better *expect* to change the value placed into it everywhere it's assigned. Otherwise it means your coworker has no idea what he's doing and you shouldn't be letting him near code. >> But, as a general rule, one should not make any significant change to >> any class member without searching for and inspecting _every_ use of >> that class member to ensure the change isn't going to break other code. > > I agree with you entirely. However, that doesn't answer my question. > >> I don't understand why one would be working in a development >> environment where it's acceptable to change the type of a property, >> but not to fix all assignments to that property to ensure that the >> type remains correct. Seems like a recipe for bugs to me. > > Once again, i do agree with you. > I'm not looking for a discussion whether it's bad or error prone way > to do things. We're already agreed on that. > > I'm looking for a good way to deal with the situation, though, once i've > found myself facing it. That's like asking if there's some way you can configure the devices plugged into your household current so that if an inept electrician replaces your 20A circuit breaker with 15A breakers but has no purpose in mind for doing so and no clue that there are implications to doing so, your devices will know to cut back on their electricity demand automatically to avoid tripping the breaker. If that's your situation, then the only valid answer is to fix the situation, not to try to work around it.
From: Peter Duniho on 5 Oct 2009 17:50 On Mon, 05 Oct 2009 11:53:47 -0700, K Viltersten <tmp1(a)viltersten.com> wrote: >>> Regard the following code. >>> >>> ... >>> this.SomeProperty = (bool)thing; >>> ... >>> >>> Suppose that we expect a co-worker to change >>> the type of SomeProperty and thing at any time. However, he/she won't >>> change the cast type. >> Your code example is difficult to follow. > > Could you elaborate which part is diffucult to follow? Well, for one...because the scenario you describe seems so remarkably broken, it's difficult to comprehend how it came up at all. The code example you provided, offers no insight whatsoever as to why what you're asking to do is in any way a reasonable, technically appropriate thing to do. In addition, the question is asked so broadly, it opens the possibility of someone changing "SomeProperty" from a bool to a string (for example), begging the question as to what it would even mean to perform the cast. > I'm looking for a good way to typecast an object to a corresponding > type of the variable i'm going to assign it to. Is it (easily) doable? No, not without modifying the code according to the change in type. The whole point of declaring something a particular type is so that you get _compile-time_ verification of the type. If you only want run-time verification, then one approach is to not bother using typed members in the first place. Just make "SomeProperty" a System.Object, and let boxing deal with conversion of value types. Presumably where the property is actually consumed, you still need to know the type and it can be cast as necessary there. Other alternatives might include changing the design so that properties of this nature are implemented more explicitly, with methods available to set the property value. Provide overloads for each anticipated input type, and write explicit conversion code in the method to handle the conversion. IMHO, this is the most reliable, because it makes it very clear what the rules for conversion of a type are, rather than your code just doing a cast and hoping for the best. Yet another option is to use the Convert class. Assuming the types you're using are all limited to those supported by the Convert class, _and_ the exact conversion provided by the Convert class are in fact the ones that are appropriate for your situation, that could work (it's basically a variation on the suggestion in the previous paragraph). > [...] > I'm looking for a good way to deal with the situation, though, once i've > found myself facing it. Honestly, faced with the situation, IMHO your best possible solution is either to fire the person who created the situation, or look for a job in a place where that kind of person doesn't exist. Pete
From: K Viltersten on 6 Oct 2009 03:14 > ...it opens the possibility of someone changing "SomeProperty" from a bool > to a string... Yes, it's exactly that sort of things i'm facing. >> I'm looking for a good way to typecast an object to a corresponding >> type of the variable i'm going to assign it to. Is it (easily) doable? > > No, not without modifying the code according to the change in type. OK. Got it. Thanks! > Honestly, faced with the situation, IMHO your best possible solution is > either to fire the person who created the situation, or look for a job in > a place where that kind of person doesn't exist. It's not my day-time job. Just a side project. The person i'm talking about is the one paying, though, so i don't think firing him will cause me any good, in this particular case, hehe. I see your point, though... -- Regards K Viltersten ---------------------------------------- May all spammers die an agonizing death; have no burial places; their souls be chased by demons in Gehenna from one room to another for all eternity and beyond. > > Pete
From: Patrice on 6 Oct 2009 04:45 (from another answer) >> ...it opens the possibility of someone changing "SomeProperty" from a >> bool to a string... > > Yes, it's exactly that sort of things i'm facing. But then you have a compile time error... Don't you ? It would be IMO worse if it was done at runtime... >> I'm curious if it can be done. AFAIK not this way (perhaps using a convoluted System.Reflection or even code generation solution ?) but the overall situation is pretty vague. As the issue seems to be in database to business object mapping code, you could perhaps select one of the technology out there and remove any need for your co-worker to mess with this. For example things such as LINQ to SQL, LINQ to Entities (which will map your data to the proper types) or perhaps DynamicData (which even creates automatically fields depending on the underlying data type). But then what will you do if your co-worker then takes other programming tasks ? -- Patrice
|
Pages: 1 Prev: listview.ItemsSource = observableCollection ques Next: Save to jpg |