Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] Testing strongly-typed collections into existence TDD and strong typed

Expand Messages
  • Charlie Poole
    Hi Thomas, ... Hmmm... I see your point. To the compiler, it s unambiguous whether a runtime action is required, so the cast doesn t seem to be adding
    Message 1 of 87 , Jul 28, 2005
    • 0 Attachment
      Hi Thomas,

      > Whenever I write a simple piece of code and the compiler
      > barks at me that implicit casting is not allowed, then I
      > think the rules are too strict. I think the rules are too
      > strict because I can't implicit downcast from object. Any
      > explicit downcast from object doesn't add any value, the code
      > is not more correct because of that, we still don't know
      > until runtime anyway whether it works or not.

      Hmmm... I see your point. To the compiler, it's unambiguous
      whether a runtime action is required, so the cast doesn't seem
      to be adding anything... except verification that the programmer
      really wants a dynamic check to occur.

      > And then, sometimes an implicit cast is allowed. When I can
      > do that sometimes, but not always, I also find that too strict.
      >
      > And when I think of it: As long as we are forced to cast
      > anything explicitly out of an untyped collection, shouldn't
      > we be forced to do the same when we put anything in? What is
      > the value of protecting the exit as long as the entrance is wide open?

      Well, an "untyped" collection is a collection of objects. So you can put
      any object into it. That makes sense to me.

      >
      > Did that answer your question at all?

      Yes, enough to know that I don't agree that C# is too strict. :-)

      I do agree that an assignment statement carries enough info to
      make the cast redundant. But it's still needed in other places
      and allowing it to be implicit in an assignment to a derived class
      would make things even more confusing.

      > --
      > Thomas
      >
      >
      > On 7/28/05, Charlie Poole <xp@...> wrote:
      > > I'm curious to know exactly what you mean by the "strict"
      > C# casting
      > > rules.
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
    • Charlie Poole
      Hi Thomas, ... Hmmm... I see your point. To the compiler, it s unambiguous whether a runtime action is required, so the cast doesn t seem to be adding
      Message 87 of 87 , Jul 28, 2005
      • 0 Attachment
        Hi Thomas,

        > Whenever I write a simple piece of code and the compiler
        > barks at me that implicit casting is not allowed, then I
        > think the rules are too strict. I think the rules are too
        > strict because I can't implicit downcast from object. Any
        > explicit downcast from object doesn't add any value, the code
        > is not more correct because of that, we still don't know
        > until runtime anyway whether it works or not.

        Hmmm... I see your point. To the compiler, it's unambiguous
        whether a runtime action is required, so the cast doesn't seem
        to be adding anything... except verification that the programmer
        really wants a dynamic check to occur.

        > And then, sometimes an implicit cast is allowed. When I can
        > do that sometimes, but not always, I also find that too strict.
        >
        > And when I think of it: As long as we are forced to cast
        > anything explicitly out of an untyped collection, shouldn't
        > we be forced to do the same when we put anything in? What is
        > the value of protecting the exit as long as the entrance is wide open?

        Well, an "untyped" collection is a collection of objects. So you can put
        any object into it. That makes sense to me.

        >
        > Did that answer your question at all?

        Yes, enough to know that I don't agree that C# is too strict. :-)

        I do agree that an assignment statement carries enough info to
        make the cast redundant. But it's still needed in other places
        and allowing it to be implicit in an assignment to a derived class
        would make things even more confusing.

        > --
        > Thomas
        >
        >
        > On 7/28/05, Charlie Poole <xp@...> wrote:
        > > I'm curious to know exactly what you mean by the "strict"
        > C# casting
        > > rules.
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.