![]() ![]() For example, unconditional calls to Nullable.Value, unconditional downcasts, dynamic objects, etc. There are "unsafe" constructs that help you make unproven assertions to the compiler. In other words, making claims is easier than proving them. This comes at a cost, however, because not only do you need to know that your program is correct, but you must write the appropriate code to convince the compiler that this is the case. Static typing gives the compiler a lot of information to be able to make rather strong guarantees about the safety of (parts of) programs. There is a trade-off between static and dynamically typed languages. Can you think of any such scenarios? Since these are also potential code smells, what design factors do you think went into the design of a feature that could produce a downcast crash without having a manifest cast in the code? This is wonderful it means that if your 100% correct understanding of type semantics turns out to be 99.99% correct, then your program works 99.99% of the time and crashes the rest of the time, instead of behaving unpredictably and corrupting user data 0.01% of the time.ĮXERCISE: There is at least one way to produce a downcast in C# without using an explicit cast operator. We have a strong guarantee that the downcast will be verified at runtime and if it cannot be verified then the program does the right thing and crashes. And the C# type system is not perfect by design it underestimates the restrictions that can be placed on the runtime type of a variable.Īlso, downcasting is very safe in C#. Why is downcasting supported by the language?Ĭ# was invented by pragmatic programmers who have jobs to do, for pragmatic programmers who have jobs to do. Downcasts were added to the language for those circumstances where it is hard and expensive to thus refactor the program. If you can cheaply refactor a program so that either the runtime type can be deduced by the compiler, or to refactor the program so that you don't need the capability of the more derived type, then do so. it is a better use of time and effort to write the cast than it is to refactor the program to eliminate either of the first two points.you need to take advantage of that fact in order to use a capability of the object not available on the compile-time type, and.you have a 100% correct knowledge of a fact about the runtime type of an expression that is more specific than the compile-time type of the expression, and.In what circumstance is it appropriate to write code which downcasts? It's so that you can more easily notice the smell and spend code review attention on it. That's why the downcasting operation is required to be manifest in the text of the program. Downcasting is extremely popular a huge number of real-world programs contain one or more downcasts. I don't believe better solutions exist.ĭowncasting is unpopular, maybe a code smell If you're going to say these are code smells, you need to provide better solutions for them (even if they are avoided due to inconvenience). Return Blah((AsyncResult)other) // another downcast (likely ~static_cast) Public override int EndRead(IAsyncResult other) Stream.EndRead/Write: class MyStream : Stream Var copy = (B)base.Clone() // known downcast (static_cast in C++)Ĭopy.x = (int)this.x.Clone() // oh hey, another downcast!! Return this.MemberwiseClone() // some sane default behavior, whatever Just ignore that and pretend this method returns type A instead of object. Again, if you dislike ICloneable, that's not the point. Return casted != null & this.x = casted.x Var casted = other as B // cautious downcast (dynamic_cast in C++) Public override bool Equals(object other) pretend it's not there and we have abstract bool A.Equals(A) instead. Nothing here, but if you're a C++ programmer who dislikes object.Equals(object), Here are some proper uses of downcasting.Īnd I respectfully vehemently disagree with others here who say the use of downcasts is definitely a code smell, because I believe there is no other reasonable way to solve the corresponding problems. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |