From: K Viltersten on
>> 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
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
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
> ...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
(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