Description
When using expression scripting, I noticed that only the type of the source itself is registered with the custom type provider. So, any type reached through a property of the source type cannot be named in an expression. This is most visible with enum-typed properties, where naming the enum type is the natural way to write the comparison. For example:
using Bonsai;
using System.Linq;
using System;
using System.Reactive.Linq;
using System.ComponentModel;
[Combinator]
[Description("")]
[WorkflowElementCategory(ElementCategory.Source)]
public class NestedEnum
{
public InnerEnum Value { get { return _value; } set { _value = value; } }
InnerEnum _value = InnerEnum.A;
public IObservable<NestedEnum> Process()
{
return Observable.Return(this);
}
}
public enum InnerEnum
{
A,
B,
C
}
Feeding the output directly to an ExpressionTransform and comparing against the enum by name fails:
Type 'InnerEnum' not found
as does casting to the enum:
No applicable method 'InnerEnum' exists in type 'NestedEnum'
However, the same expressions work fine when InnerEnum becomes the source type.
In practice, any source type that exposes its "useful" objects behind a property does not get those types registered. I'm not sure if there are specific gotchas with the following approach, but could this be fixed by expanding the EnumerateTypeHierarchy method in src/Bonsai.Scripting.Expressions/ParsingConfigHelper.cs to walk the properties of the object as well as the interfaces and the base chain of the type it is handed?
Description
When using expression scripting, I noticed that only the type of the source itself is registered with the custom type provider. So, any type reached through a property of the source type cannot be named in an expression. This is most visible with enum-typed properties, where naming the enum type is the natural way to write the comparison. For example:
Feeding the output directly to an
ExpressionTransformand comparing against the enum by name fails:as does casting to the enum:
However, the same expressions work fine when
InnerEnumbecomes the source type.In practice, any source type that exposes its "useful" objects behind a property does not get those types registered. I'm not sure if there are specific gotchas with the following approach, but could this be fixed by expanding the
EnumerateTypeHierarchymethod insrc/Bonsai.Scripting.Expressions/ParsingConfigHelper.csto walk the properties of the object as well as the interfaces and the base chain of the type it is handed?