[suggestion] anonymous array declaration, relax object syntax (JS/Json syntax)

[lofcz]

Currently EE can evaluate anonymous object declarations:

x = new {a = 10, b = 20, c = 30}

property = value is enforced in method InitSimpleObjet (we should rename that to InitSimpleObject). First part of this suggestion is to relax this syntax and allow customization (preferably in the way customization of new works now) such as:

x = new {a: 10, b: 20, c: 30}

second part of this suggestion proposes support of JS-like anonymous array declaration (respecting c# new initialization pattern), which would internally map to List<object>:

x = new [10, 20, 30] // x[2] = 30

@codingseb do you think this would be possible to implement and of use?

[codingseb]

Good idea. I was just thinking about this these days. A JS/JSON syntax could be great.

I will probably create a few options for this.

like :

OptionJsonSyntaxForAnonymousObjectInit = true;
// for
x = new {a: 10, b: 20, c: 30}
// ...

OptionAllowStringForPropertiesInAnonymousObjectInit = true;
// for
x = new {"a": 10, "b": 20, "c": 30}

OptionAllowToOmitInitializationKeywordForAnonymousObjectInit  = true;
// for
x = {"a": 10, "b": 20, "c": 30}

InitSimpleObjet (we should rename that to InitSimpleObject)

Oops this is my French that popup.

[lofcz]

@codingseb great idea. To keep consistency with newly added OptionNewKeywordAliases and OptionScriptEndOfExpression and allow for a broader range of usages I think this would be better as:

EE.OptionSyntaxRules.ObjectInitPropertyValueDelimiter = string[] {'='}
                    .ObjectInitAllowPropertyAsString = false
                    .KeywordNew = string[] {'new'}
                    .StatementTerminalPunctuators = string[] {';'}

• Introduce class OptionSyntaxRules which would hold all syntactic options to improve discoverability by end user (instead of going trough all options I can just list members of this class).
• By default all options would be string[] (where makes sense) to support free mix and match of multiple styles.

OptionSyntaxRules.ObjectInitPropertyValueDelimiter = new {"=", ":"};

x = new {a: 10, b = 20}

• Naming of members would follow noun first pattern.
• StatementTerminalPunctuators could replace OptionScriptEndOfExpression, as semicolons are formally called punctuators in c++ spec:

The lexical representation of C++ programs includes a number of preprocessing tokens which are used in the syntax of the preprocessor or are converted into tokens for operators and punctuators

• KeywordNew could replace OptionNewKeywordAliases 'aliases' here (at least for me) sounds like we always keep and enforce original new and only allow to add aliases for it, which in fact is not true as we already allow for example:

OptionNewKeywordAliases = new {"->"};

in which case only -> can be used instead of new and new is not recognized as a keyword.

[codingseb]

I am currently reflecting about this. I try to start the implementation.

I agree that Options need to be refactor to offer a better intellisense experience. But as it introduce breaking changes. It means that it will be included in next major version and consequently Json/JS syntax stuff too. So I will work on this in branch MakeScriptEvaluationMoreFlexible with others stuffs that need to be finish in it.

Also, for the arrays options I am not sure that it will be possible everywhere without changing a lot of stuffs (and taking a lot of time) so to go forward with this, maybe I will firstly propose simpler version of some options. I mean maybe just a simple string option to start.

[codingseb]

I already published an alpha version for v.1.5 from branch MakeScriptEvaluationMoreFlexible (See on nuget) to test some early features. We can test it here It already contains some cool script customization stuff and support Json syntax.

evaluator.OptionsSyntaxRules.IsNewKeywordForAnonymousExpandoObjectOptional = true;
evaluator.OptionsSyntaxRules.InitializerPropertyValueSeparators = new[] { "=", ":" };
evaluator.OptionsSyntaxRules.InitializerAllowStringForProperties = true;
evaluator.OptionsSyntaxRules.AllowSimplifiedCollectionSyntax = true;

// And we can also use (To do a List<object> in place of a object[]): 
evaluator.OptionsSyntaxRules.SimplifiedCollectionMode = SimplifiedCollectionMode.List;

Take note that it introduce some breaking changes with previous versions and some others breaking changes can still happend until the official 1.5.0.0 release For now there is no documentation for new features

[lofcz]

Great news @codingseb thanks for all the effort you are putting into this!