Plan to improve support of array-like CLR Object

[viruscamp]

1. Support Indexer set
2. Write array-like prototype for c-sharp T[], IList, IList<T> and any class with int Length {get;} and T this[int]
3. Set the prototype for ObjectWrapper
4. Remove result = ConvertArray(engine, a); in bool DefaultObjectConverter.TryConvert(), wrap array in ObjectWrapper
5. I may combine TypeReference and TypeDescriptor and set it to ObjectWrapper._prototype. This may break API compatibility.

I'll try my best to pass existing tests and add new tests to cover the new features. Any problem? @lahma

[lahma]

On mobile, but some earlier discussions for starters:

#1030

#1585

Maybe #721

So there's already some detection logic for array likes. ObjectWrapper sniffs some things.

The prototype can be a bit tricky if the object is not owned by Jint. I think I went through the thinking process at some point but probably have forgotten. In-place mutating methods would probably require writing (and maintaining!) duplicate set of functions and anything out-of-sync or different behavior would again cause bug reports or hard to debug scenarios.

Despite the former worries, I'm not entirely opposing these new features. Maybe need to do it in small bites and having careful consideration with JS semantics vs .NET.

[viruscamp]

Some further points:

1. Use duck typing:

• HasGetEnumerator: has a public method Enumerator GetEnumerator()
• HasCount: has a public property int Count { get; } or int Length { get; }
• HasIntIndexer: has a public Indexer T this[int idx] { get; }

2. We have three js target type

• js iterable: HasGetEnumerator, add js property [Symbol.iterator]
• js array-like: HasCount + HasIntIndexer
• js array: HasGetEnumerator + HasCount + HasIntIndexer, add more js methods like shift, sort, every and so on.

3. Additional info for dotnet Type:

• IsTyped
• IsReadOnly
• IsResizable

[viruscamp]

					IsTyped
							IsReadOnly
HasGetEnumerator			IEnumerable
					IEnumerable<T>
	HasCount		ICollection		ICollection<T>		IReadOnlyCollection<T>
		HasIntIndexer	IList		IList<T>		IReadOnlyList<T>

[viruscamp]

Thinking about dotnet types:

1. A type X won't be treat as IList, if X implement one of IList method explicitly.

       public bool IsImplicitInterface(Type type, Type interfaze)
       {
           foreach (var m in type.GetInterfaceMap(interfaze).TargetMethods)
           {
               if (!m.IsPublic)
               {
                   return false;
               }
           }
           return true;
       }

2. class X implicit interface or public methods/properties
3. Known interface IEnumerable to IList<T>, IEnumerator<T> GetEnumerator() cannot be treat like that in class

var ilistint = typeof(IList<int>);
var ilistinterfaces = ilistint.GetInterfaces(); // IEnumerator, IEnumerator<int>, ICollection<int>, no IList<int>
var ilistmethods = ilistint.GetMethods(); // IndexOf, Insert, RemoveAt, get_Item, set_Item, no GetEnumerator, no get_Count
var ilist_GetEnumerator = ilistint.GetMethod("GetEnumerator"); // null

4. Unknown interface interface IX : IList<int>, IList<IList<string>>, no implicit/explicit interface as in class, that is coexisting of two IList<>

public interface IListAndDictionary : IList<string>, IReadOnlyDictionary<int, string> {}

var iboth = typeof(IListAndDictionary);
var ibothinterfaces = iboth.GetInterfaces(); // 6
var ibothmethods = iboth.GetMethods(); // 0
var iboth_GetEnumerator = iboth.GetMethod("GetEnumerator"); // null

5. Coexisting of two interfaces means implicitly implement both
   implement interface method must exactly follow the signature

• IList and IDictionary can coexist in a class both implicit implemented, due to one may write class CrazyEnumrator ：IEnumerator, IDictionaryEnumerator can not coexit.
• IList<A> and IDictionary<int, A> can not coexist.
• IList<A> and IDictionary<K, B> can not coexist, when K is not int.
• IList<A> and IList<B> can not coexist
• IList<string>, IList can not coexist
• IList<A> and IList<B> , if we have T: A, B, may coexist from the view of function, but cannot coexist from the view of property

  public T get_Item(int idx);
  public void set_Item(int idx, A v);
  public void set_Item(int idx, B v);

[viruscamp]

Duck typing and implicit interface are suitable for abstract class:

public interface IX<T>
{
	T Print();
}

public abstract class X : IX<int>, IX<string>
{
	public abstract int Print();

	string IX<string>.Print()
	{
		throw new NotImplementedException();
	}
}

[viruscamp]

Some known problems:

1. CLR Array int[] is converted to a new created js array, cannot be changed inplace.
2. CLR List<T> is treat as IList, setter does not known the type, raise fail

      [Fact]
      public void CanUseIndexOnGenericList()
      {
          var list = new List<int>() { 3, 4 };
          _engine.SetValue("list", list);
          _engine.Evaluate("list[1] = 42;");

          Assert.Equal(42, _engine.Evaluate("list[1]"));
          Assert.Equal(3, list[0]);
          Assert.Equal(42, list[1]);
      }

3. get indexer on List<ExplicitInterface> get Object instead of ExplicitInterface, Because inner get use IList not IList<T>
4. iterator on List<ExplicitInterface> get Object instead of ExplicitInterface, Because inner iterator use IEnumerable nor IEnumerable<T>
5. Jint.Tests.Runtime.InteropTests.CanUseIndexOnCollection is wrong, Because System.Collections.ObjectModel.Collection<> is a IList<>. ICollection cannot be indexed.

[viruscamp]

Problems may occur:

1. Same name methods with different usage:

• array.join() and Enumerable.Join() totally different
• array.reverse() mutate list in-place , Enumerable.Reverse() create new list

2. array.flat() and array.flatMap() are not suitable for typed c# collections.
3. duck typing confused on IDictionary<int, T>

var dict = new Dictionary<int, string>() {
    { 3, "" },
    { 24, "abc" },
};

compared to

var dict = { length: 2, 3: "", 24: "abc" };

[lahma]

I think this is a good example why we couldn't automatically consider input as JsArray unless it was safe to convert to new representation, which does not reflect back to call side.

[viruscamp]

The usage of Engine.Options.Interop.AllowWrite is confusing, may be useless.
It cannot prevent mutation in method call.
Writing to Property and Indexer can be easily bypassed by call set_Property and set_Item methods.

[viruscamp]

What to do for CLR array-like objects:

1. add [Symbol.iterator] property, to make for (var x of iterable) works

• Strong typed Enumerator<T> must be first choice
• for duck typing Enumerator<T> GetEnumerator() or Enumerator GetEnumerator()
• for type IEnumerable<T> or IEnumerable
• problem 1: IList<T> must be carefully checked

2. add length property

• for duck typing int Count { get; } or int Length { get; }
• for type ICollection<T> or ICollection
• problem 1: IList<T> must be carefully checked
• problem 2: IDictionary<int, T> should the Count treat as length?

  var dict = new Dictionary<int, string>() {
      { 3, "" },
      { 24, "abc" },
  };

3. indexer setter and getter

• Must be mutated in-place
• Strong typed

4. attach a prototype

• generic array methods said only length and this[int] should be used, not the [Symbol.iterator]
• emtpy slots: should we translate IndexOutOfBoundsException and ElemememtNotFoundException to undefined