You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is something that came up from working through the documentation guides, converting existing Ruby and JS examples to C#.
The dynamic context feature, where map structures passed to generate get converted to temp rules in the registry at runtime is very much an API feature that emerged from dynamic language thinking and template engine APIs. It’s an important feature to have because it opens up a whole lot of useful patterns that would not be possible with purely static grammars, but translating it to C# well is not as obvious/direct as just flinging around a bunch of untyped data structures as certain other languages encourage.
Example of one of the documentation examples translated to a C# test:
usingUser=System.Collections.Generic.Dictionary<string,string>;// etc...[Test]publicvoidAppWelcomeMessageExample(){Grammargreeting=newGrammar(G =>{G.Start(new[]{"Hi {username}","Welcome back {username}","Hola {username}"});});Useruser=newUser{{"name","Erika"}};Resultresult=greeting.Generate(newDictionary<string,string[]>{{"username",new[]{user["name"]}}});Assert.That(result.Text,Does.EndWith("Erika"));}// etc...
A couple of things here which make the API more complicated to use:
Dynamic context must specify uniform branches explicitly with string[]—there is no shortcut for a uniform branch with one entry to be input as a bare string, as supported by the static rule API. This is available implicitly in the dynamic language ports, and its absence could be confusing here if people are moving from JavaScript to C#.
Weighted probability branches are unsupported. This is understandable from the perspective of keeping the implementation simple and it is probably an edge case here. But it is available implicitly in the dynamic language ports.
An example from the JS port that doesn’t currently work in C#:
To improve the usability here, perhaps we could provide a builtin Context type which does a little bit of polymorphism housekeeping and internal wrangling on the key types to support simpler injection of dynamic state, rather than the brute force hammer solution of something like Dictionary<string, object> which potentially opens up a whole new area of bugs and mistakes.
The text was updated successfully, but these errors were encountered:
A potential implementation concept using the dynamic type from .Net 4. The polymorphism currently built-in to the Grammar.Rule method does a lot of the heavy-lifting here. Not without its problems, and still needs to be tested/verified in Unity, but is at least a starting point for thinking about the direction for this feature.
This is something that came up from working through the documentation guides, converting existing Ruby and JS examples to C#.
The dynamic context feature, where map structures passed to generate get converted to temp rules in the registry at runtime is very much an API feature that emerged from dynamic language thinking and template engine APIs. It’s an important feature to have because it opens up a whole lot of useful patterns that would not be possible with purely static grammars, but translating it to C# well is not as obvious/direct as just flinging around a bunch of untyped data structures as certain other languages encourage.
Example of one of the documentation examples translated to a C# test:
A couple of things here which make the API more complicated to use:
string[]
—there is no shortcut for a uniform branch with one entry to be input as a barestring
, as supported by the static rule API. This is available implicitly in the dynamic language ports, and its absence could be confusing here if people are moving from JavaScript to C#.An example from the JS port that doesn’t currently work in C#:
To improve the usability here, perhaps we could provide a builtin
Context
type which does a little bit of polymorphism housekeeping and internal wrangling on the key types to support simpler injection of dynamic state, rather than the brute force hammer solution of something likeDictionary<string, object>
which potentially opens up a whole new area of bugs and mistakes.The text was updated successfully, but these errors were encountered: