Closed chlowell closed 4 years ago
+ public interface INotifyPropertyChanged {
+ event PropertyChangedEventHandler PropertyChanged;
+ }
Maybe I'm reading the proposal incorrectly, but isn't INotifyPropertyChanged
already in .NET Core?
You're correct, thank you. I missed that assembly while building the diffs. I've removed the types in System.ObjectModel
from the proposed additions.
Some comments on the proposed collections:
+ public class AttributeCollection : ICollection, IEnumerable {
+ public static readonly AttributeCollection Empty;
+ protected AttributeCollection();
+ public AttributeCollection(params Attribute[] attributes);
+ protected virtual Attribute[] Attributes { get; }
+ public int Count { get; }
+ int System.Collections.ICollection.Count { get; }
^ Since there is a public `Count` property, there's no need
| to add this explicitly implemented member to .NET Core.
+ bool System.Collections.ICollection.IsSynchronized { get; }
+ object System.Collections.ICollection.SyncRoot { get; }
+ public virtual Attribute this[int index] { get; }
+ public virtual Attribute this[Type attributeType] { get; }
+ public bool Contains(Attribute attribute);
+ public bool Contains(Attribute[] attributes);
+ public void CopyTo(Array array, int index);
^ Should this `CopyTo` be implemented explicitly? For example, other older collections
| like `System.Text.RegularExpressions.MatchCollection` implement `CopyTo(Array, int)` explicitly (private)
| in .NET Core, whereas it is public in the full framework. This would open the door to adding
| a strongly-typed `public void CopyTo(Attribute[] array, int index)` in the future without
| the baggage of a weaker-typed public `CopyTo` overload.
+ public static AttributeCollection FromExisting(AttributeCollection existing, params Attribute[] newAttributes);
+ protected Attribute GetDefaultAttribute(Type attributeType);
+ public IEnumerator GetEnumerator();
+ public bool Matches(Attribute attribute);
+ public bool Matches(Attribute[] attributes);
+ IEnumerator System.Collections.IEnumerable.GetEnumerator();
^ Since there is a public `GetEnumerator` method, there's no need
| to add this explicitly implemented member to .NET Core.
+ }
Same feedback applies to the other proposed collections.
Thanks for posting this issue, I'd greatly appreciate seeing the DescriptionAttribute added as it's the only true portability issue for my enum utility library.
In yesterday's API review (dotnet/apireviews#32) we decided to add DescriptionAttribute
as well.
:+1: Awesome, that's great news.
I've created a dev/typedescriptor branch for this work
Just watched the Video. Just wanted to give some information where the TypeDescriptor is commonly used, besides the Designer. Most DataGrid implementations are using this infrastructure to get Information about the data to show, probably because of DataSet, DataTable and so on. WPF Bindings are using it! Also MVC x -5 use these to reflect the meta data from the objects, but in that case only the typebased implementation not the instance based one. See also: [1]
My guess (and also why i would like to see it in corefx) why this is used so much is, that it is the only Framework supported contract for getting metadata from an object that not necessarly exists as concrete type. I tried other ways to achieve the same solution but they don't work, even though you can try to implement your own Type (as Type is abstract and public) the code doesn't behave the way you want it to.
I would like to see an official API that can be used to reflect information about object that does not exists as Types directly. Otherwise you often need to compile these types into dynamic assemblies and then reflect them again, which ist a lot of overhead, if this happens often.
This is especially important for instance based implementations.
This Model for example
class EntityType{
public string Name {get;set; }
public Collection
class EntityField { public string Type {get;set;} public string Name {get;set;} }
public class Entity{ public EntityType Type {get;set;} public Dictionary<string,object> Data {get;set;} }
To make it show up in an Win Forms or WPF i just implement and Instance based TypeDescriptor and it magically works as if it was a Type with real properties etc.
We've started implementing these APIs. You can see the work in progress on the dev/typedescriptor
branch. Do you often use TypeDescriptor
outside of Forms, WPF, or MVC scenarios?
I wouldn't say often, but i think its a good concept to write code not against reflection itself but against TypeDescriptor and have a reflecting TypeDescriptor instead, this allows for really flexible code and use cases of your framework or components. WPF Binding is a really good example of how this scales to custom dynamic objects. On the other hand i don't think TypeDescriptor was designed for this, it just happend to be. So i would welcome a rehaul of its API but think all in all the concept really should be in the core framework.
System.ComponentModel
is a common dependency of applications developed for the .NET Framework. Porting these would be easier if more of the namespace were available in .NET Core. This issue proposes to addSystem.ComponentModel
members with no designer, UI, or other unavailable dependencies.Proposed additions
.NET Framework vs .NET Core proposed