Type cast depending on the reciever type

[K Viltersten]

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.

Is there a nice way to get around it? I'm
thinking along the lines of the following.

...
this.SomeProperty =
(typeOf(this.SomeProperty))thing;
...

Suggestions?

 

[Peter Duniho]

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. 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. Type safety is not the only
important kind of code correctness there is.

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.

Pete

 

[Harlan Messinger]

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.

I agree with you entirely. However, that doesn't answer my question.


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.

 

[K Viltersten]

What is the expected benefit? IMO you should

start by explaining the overall goal.

I'm curious if it can be done. I have a sort
of work around but i'm not proud of it. To
asnswer your question - the expected benefit
is to be able to avoid the error described,
i.e. the situation where somebody changes the
type of a property and updates the stored
procedure returning the value but can't (or
forgets) to updata the data access layer.

For now it seems that you want just to take
some responsability ouf of your co-worker.

The organizational task of our project is not
my liberty to affect. By other words, we can
agree upon the stupidity of the situation all
we can - it will still remain to be a problem
and i wish to find a better solution that
going into that DAL class every second week
and changing the type that obejcts from the
database are cast into.

At some point, when coding, you have to know
what you are doing.

I agree. However, i'm not going to be at that
point when it comes to this individual matter
any time soon.

Or perhaps do you have some other goal...?

Well, when getting data from a database, one
needs to rely on the correctness of teh type
it's being case to. It'd be nice if it'd be
cast automagically to the correct type,
picked by the designer of the property.

Once again, i feel i need to emphasise that
we're on the same page regarding situation at
hand. I'm not liking it but i can't affect
it. I'd like to nag about my problems but
that won't certainly not solve them...

 

[Harlan Messinger]

I'm not sure how it relates to typecasting but what i do know
is that my original question was if it's possible to typecast a
variable to a type that is programmatically determined. Is it
doable at all in C#?


Thanks for the advice. Since i can't affect my current situation in the
project, i can't really use it, though. I'll
have to conclude that i'll need to keep correcting the
code piece all over every now and then.

Thanks for trying!

Wow! Why is telling this alleged programmer "Don't go changing data
types if you don't know what you're doing" not an option?

 

[K Viltersten]

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...

I'm not sure how it relates to typecasting but what i do know
is that my original question was if it's possible to typecast a
variable to a type that is programmatically determined. Is it
doable at all in C#?

If that's your situation, then the only valid answer is to fix
the situation, not to try to work around it.

Thanks for the advice. Since i can't affect my current
situation in the project, i can't really use it, though. I'll
have to conclude that i'll need to keep correcting the
code piece all over every now and then.

Thanks for trying!

 

[Peter Duniho]

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

 

[Jesse Houwing]

* K Viltersten wrote, On 5-10-2009 10:17:

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.
Is there a nice way to get around it? I'm thinking along the lines of
the following.

...
this.SomeProperty = (typeOf(this.SomeProperty))thing;

From what I understand you'd like to fix the runtime error and replace
it with another runtime error.

The thing you'd really want to do is to fix the runtime error by adding
additional checks, or make sure you use type safety in the first place
to generate a nice compiler error.

Why is this case in the code in the first place?
Why is thing of a type that is (by default) not assignable to SomeProperty?

If you're the owner of both components, it should be easy to fix for
good, and you'll no longer need the cast in the first place.

Another issue with this code is that it would change all the code
referencing this.SomeProperty in this way, without you checking if it's
actually possible. You'd introduce loads of unsuspected bugs and other
nasty stuff. And yet another problem is, that while this code might
compile in this class, what would happen if you use some library that
referenced the object that contains SomeProperty. Would it dynamically
recompile to match the new type? No! That isn't possible.

You should wrap thing in something that does the type checking and
conversion, so that you'd only have to fix it in one place. If you
expect it to change often. Or leave the cast in place and fix it when
the change occurs. It's not there without a good reason!

 

[K Viltersten]

That's like asking if there's some way you can configure the devices

Wow! Why is telling this alleged programmer "Don't go changing data
types if you don't know what you're doing" not an option?

Because he's the one to pay me. Rather well, may i add.
However, he doesn't accept criticizm...

It's an not my usual work, just a side project, so i don't
exactly have a boss to go to cry to. I figured out, the best
way is to "get around" it, hehe.

 

[K Viltersten]

...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.

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...