![]() Since the compiler can only know that the type of the item is Object, you have to explicitly cast to a more specific type in order to perform any operation (and that cast may of course fail at runtime if you get the wrong type.) So Session is equivalent to a Dictionary. This means the static type of the stored items must be Object. The Session object is designed to let you store objects of any type. The underlying issue is not Session or Asp.Net specific, it is a fundamental issue in how collections in statically typed languages work. ![]() It's a computer program after all, not anything magical, or am I still missing something? ![]() I don't get why "there is no other option". Regarding comment: "You have to be able to save all kinds of different objects in a Session, so the type has to be Object, there is no other option" Why the following code: Session = 0 Ĭan't be translated, by compiler, at the compile-time, to something like this: int SessionIndex = 0 Just to clear the air, my main question is why the Session has implemented in this way? What are the benefits of having a session like this - whatever it is, rather how it has implemented - even though I'm looking to know that as well. Also wondering if there is anything related to how other languages like Java or C++ have implemented sessions, either directly in the language itself or via a library, so it led the Asp.net team as well to implement session like that? What would happen if you try to assign a string to this integer variable? Well, like everything else in a statically typed language, you will get an exception.Īm I missing anything here? I simply can't understand why such a design decision has been made by the Asp.net development team and how the developer could benefit from that. Second, if we assume that the session variables also has to be statically typed, then is it "technically" possible to implement Asp.net's session in a way that when you define a session variable like below, the compiler allocates the memory in the heap, keep the data type next to it and simply eliminates the need for casting it each time? Session = 0 // integer type, available at compile-time What I'm thinking is, first, why you need to have such a feature only for the session, in a statically typed language like Asp.net/C#? For example, what is the use case of defining a "session" variable as an integer, but then put string on it at the run-time? Is there any practical use case and requirement for such a feature, not only in Asp.net but any other language? As my colleagues say, that's because you can basically have a dynamically typed session object, at run-time. I'm not sure if that's the case or not or even if I have understood it properly, but what I don't understand is why it has to be implemented in a way that the developer has to cast it before using it. Session = ((int)Session) + 1 // it works hereĪsking my C# developer colleagues, it seems that the Session is somehow an object that covers up the actual data type of the variable, apparently without losing it, but for some reason you still need to cast it anyway any time you want to access it. Session = Session + 1 // throws exception ![]() When working with the session, regardless of the data type that I was specifying for the session variable, I had to cast the session variable any time I needed to access it. I'm not a Asp.net/C# developer myself but recently had to slightly refactor a Asp.net/C# project and I had to use Session at some point.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |