nicholasudell / controlstrings Goto Github PK

Transformers are special objects that operate on the result of a control string. The most common use case I can see is for capitalization.

For example, {Person:Pronoun:Singular} bring{Person:Pronoun:VerbEnding} you a gift results in:

he brings you a gift
she brings you a gift
they bring you a gift

Whereas, with the pronoun at the start of the sentence, it should be He/She/They respectively.

Proposed syntax for an example CapitalFirst Transformer:

{Person:Pronoun:Singular|CapitalFirst} bring{Person:Pronoun:VerbEnding} you a gift

The vertical bar denotes that the result of the control string will be piped into the transformer.

Further considerations:

• Should we allow the results of a transformer to be piped into another transformer in the chain? For example: {Person:Pronoun:Singular|CapitalFirst|Reverse} to make strings like eH or ehS or yehT
• Should we allow contextual transformers?
• Since they're typically a global concern, like capitalisation, how do we handle their registration?

At the moment the only guidance on how to use this is the Example.cs file included in the source.

That's pretty unacceptable.

It would simplify syntax and reduce small class clutter if we could include a ternary syntax conditional Control String Matcher.

Such a string would perhaps take the format {context:name?valueIfTrue:valueIfFalse} (from Example.cs)

{Person:Pronoun:Singular} bring{Person:Pronoun:IsAlwaysPlural?:s} you a gift

This would resolve to:

he brings you a gift

or

they bring you a gift

As long as the They pronoun returned true for IsAlwaysPlural

This would be set up something like this (in class Pronoun):

new ConditionalControlStringMatcher("IsAlwaysPlural", () => AlwaysPlural))

Some questions to consider:

• Should the ControlStringMatcher definition allow modifying the result? In the above example, we could add additional, optional parameters to provide funcs that take the passed in ternary values ("" and "s") respectively, and then modify them some way based on internal logic.
• Should we allow variables in the results? For example {Person:MiddleName:Exists?MiddleName:} which would only show a person's middle name if it existed.
• Should we allow the context tree to go deeper? For example, allow something like {Person:MiddleName:Exists?MiddleName:Initial:} which would print the initial of the person's middle name if one exists, otherwise blank.

StringBuilders concatenate strings using fewer allocations and are generally faster. Since building these strings could theoretically result in a huge number of concatenations, StringBuilder is the way to go.