Re: Cast generic IFoo<T>

Tech-Archive recommends: Fix windows errors by optimizing your registry

On Thu, 24 Jul 2008 11:29:19 -0700, Jon Skeet [C# MVP] <skeet@xxxxxxxxx> wrote:

If you don't know it in a compiler-provable way, then again: I think
that's not comparable to the OP's situation (his code specifically shows
an explicit type declaration).

In the method call, yes. He may know that he can cast to IFoo, but not
know which IFoo<T> to cast to. We don't know enough about the situation
to say, IMO.

I didn't have the impression from the original post that he even has a non-generic IFoo interface, never mind that he has code that knows it can cast to that without knowing the type parameter T.

But I'll concede that until the OP comes back and comments on it, we don't know for sure one way or the other. I'm basing my interpretation solely on his wording and what seems to be the kind of question that might be asked along these lines. I admit there's no hard facts in the original post that assure us of one interpretation vs. another.

So if you like, I'm happy to rephrase my original statement to account for that.

> Yes it does - because I can guarantee (in my situation) that it will
> have been created as an IList<T> somewhere. Even if the ICountable
> interface existed, however I couldn't necessarily ensure that the
> implementation of IList<T> also implemented ICountable.

At the risk of belaboring a point I think is irrelevant to the original
question: but why would that matter?

Because I want to know that I can cast to ICountable whenever I know
that something implements IList<T>.

To me, that suggests a goal specifically served by just the inheritance you're proposing. That is, you're not just trying to pass a type-parameterless instance of IList<T> to something, but rather you have a specific desire to connect the two interfaces. You specifically want one fact to imply the other.

I can't disagree with that as a motivation for inheriting the interface. After all, to me that's what the inheritance is all about. But that seems separate from the goal of being about to get a count from the object.

I already know that I can cast to
IEnumerable, and I'm using that in the code - ICountable would be the
equivalent but to retrieve the count.

But is it really so much more important to be able to cast without a check?

I'm all for taking advantage of implicit information when possible, but imposing interface implementations arbitrarily seems unnecessary.

[...]
If you already know for sure it's created as
IList<T>, then even better, should you happen to also want to use the
instance as an IList<T>.

But as I only have a compile-time reference as "object" I would have to
go to a fair amount of nasty reflection work in order to use any of the
IList<T> members.

That's true. And it's debatable whether IList<T> should have included as part of its own definition members that don't actually need the type T. Perhaps from the outset, it would have made more sense to factor out the non-type-dependent parts into a non-generic interface inherited by IList<T>.

But with respect to the original question, I don't see that being the proposal. To me, an IFoo as a non-generic version of IFoo<T> would be just like IFoo<T> except without type. That is, the type parameter would be replaced by "Object" everywhere.

I see that proposal as fundamentally different from what you're talking about.

Now, granted...the proposals to make a non-generic interface that IFoo<T> inherits are about as vague as the original question was. I'm making assumptions about how that IFoo interface would be declared, and those assumptions might not be the intent of the original proposal. But at the very least, those assumptions should be corrected by those proposing to create a new type. :)

Pete
.

Relevant Pages

  • Re: Tired of 100s of stupid Getter/Setter methods
    ... but interface does not hide the other methods of implementing ... telling you that you need to refactor a new common superclass. ... Again, composition instead of inheritance. ... A StringVector cannot take Integer parameters. ...
    (comp.lang.java.programmer)
  • Re: Operator overloading [was Re: 7.0 wishlist?]
    ... I doubt Harry was proposing that the translation be naïve. ... public interface Addable{ ... BigDecimal--would be powerful enough, even if operator overloading ... String and return a String, ...
    (comp.lang.java.programmer)
  • Re: A taxonomy of types
    ... (I do not see why inheritance is required here.) ... without an »object-oriented programming language«, for example, ... in the programming language used. ... indirectly) implements an interface IA whose declaration ...
    (comp.lang.misc)
  • Re: Beginner, Which language
    ... > That's much more true for implementation inheritance than interface ... > compared to the run time support Java requires. ... > - All base classes of the interface must also be declared with interface ...
    (comp.programming)
  • Re: Pulling my hair out, I need some help
    ... base class was just that i noticed that a base class saved me more typing ... as using the interface, to the other programmers in my company i made both ... is that the plug-in must meet. ... Inheritance, it is less clear which methods and properties of the ...
    (microsoft.public.dotnet.languages.vb)