How do you pass into a method a generic after you've reflected? [Answered]
Suppose I suspect that this IEnumerable (non-generic) is also an IReadOnlyList<T> where T : struct.
Unfortunately due to the rules of casting, an IReadOnlyList<T> where T : struct is not castable to an IReadOnlyList<object>
How unfortunate! But we have reflection!
Suppose I have an IEnumerable called source. I can probe its types as follows
Another class takes in as an argument to its constructor, IReadOnlyList<T> Defined below:
How do I after probing call this constructor now that I know it implements the interface as required?
24 Replies
Is there a reason you need to do this via reflection?
I think you can just do
though for that you need a
T
given somehow.
If that's not possible, you can do
But if it's at all possible for you I'd strongly recommend just handing through the generic argument several times, instead of loosing the type somewhere and then restoring it in this wayI do not have T known.
In that case the second solution should work. Not very pretty and you loose a bunch of type safety (you also get back an
object
, so...)Oh so I do.
Yeah I agree that this isn't pretty, but this is already the backwards-compat slow code-path anyway
fair enough 😛
Related to AvaloniaUI PR 8764 if you're interested
https://github.com/AvaloniaUI/Avalonia/issues/8764
GitHub
For Avalonia.Controls.ListBox for Items Property, Support for IRead...
Describe the bug For a DataContext View-Model that has Specialized Collections, collections may implement the IList<T> or IReadOnlyList<T> interfaces, neither of which i...
About collections that don't implement non-generic IList
Hence all of the weird casting going on
Remember that IList (non-generic) and IReadOnlyList<T> have nothing in common outside of IEnumerable
IEnumerable
should just not exist in modern .NET but yeah legacy code...
Also I don't really understand your issue.
Imo it doesn't make sense to ever have a type that implements IReadOnlyList<T>
and INotifyCollectionChanged
but not some kind of IList(<T>)
Given INotifyCollectionChanged
only makes sense if the collection can actually change, but IReadOnlyList<T>
explicitly can't change
Like, in what case would the event fire?My point is that IList<T> extends IReadOnlyList<T>
Supporting a viewer that works with IReadOnlyList<T> by definition must work with IList<T>
Presuming that the interface contract is implemented correctly
due to legacy reasons that 's not true though
IList<T> does not extend IReadOnlyList<T>
👀
yup.... IList<T> is .NET FX 2.0 and IReadOnlyList<T> is .NET FX 4.5 :/
Oh and here I thought ICollection<T> : IReadOnlyList<T>
What on earth are these interface
✨ legacy code ✨
And you have a whole bunch of classes that implement IList but don't implement IReadOnlyList<T> now?
not really
I mean .NET types all implement both iirc
it's just the rare externally implemented collection type might be weird now
Do you actually have a type that implements IReadOnlyList<T> and INotifyCollectionChanged, but not IList(<T>)????
It implements IList<T>
But not non-generic IList
I was under the impression that IList<T> : IReadOnlyList<T>
But that is clearly wrong.
oh
that is actually somewhat reasonable and imo an oversight in avalonia
Ah, but maxkatz6 says by-design.
Perhaps they thought I knew that IList<T> does not extend IReadOnlyList<T>
I am not so competent, clearly.
I think the part of your issue that says IReadOnlyList<T> is by-design, but that it doesn't support IList<T> is a valid problem imo
can't imagine they disregard that too as by-design 🤔
Okay but I feel like it would weird to close this one and then immediately raise a new issue about not supporting IList<T>
looks like they are fine just discussing it as is?
Yeah, maybe I'm just overreacting to the label change
✅ This post has been marked as answered!