[
https://issues.apache.org/jira/browse/GROOVY-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420022#comment-17420022
]
mgroovy commented on GROOVY-10259:
----------------------------------
https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/main/groovy/org/apache/groovy/ginq/provider/collection/runtime/NamedTuple.groovy
> Groovy4 NV Macros: Rename NV* -> SV*
> ------------------------------------
>
> Key: GROOVY-10259
> URL: https://issues.apache.org/jira/browse/GROOVY-10259
> Project: Groovy
> Issue Type: Proposal
> Affects Versions: 4.0.0-beta-1
> Reporter: mgroovy
> Priority: Major
>
> According to the release notes
> ([https://groovy-lang.org/releasenotes/groovy-4.0.html]) "stringify" macros
> will be released with Groovy 4, using a NV* naming convention.
> I propose to change the "stringify variable" macro names from
> NV/NVI/NVD
> to
> SV/SVI/SVD
> Rationale:
> * The planned Groovy4 NV macros immediately (G)Stringify their arguments,
> always creating the same fixed textual representation (which cannot be
> processed further in any meaningful way).
> * NV is the macro name I originally proposed (and currently use), but it
> returns a NameAndValue instance (see below for a slightly simplified version
> of my in any case trivial NameAndValue class), instead of directly returning
> a String representation
> ** The NV macro name was chosen since it mirrors the name of the class it
> creates, which holds the stringified expression ("name") that has been passed
> to the NV macro, together with a reference to the result ("value") of
> evaluating said expression, i.e. in the end holds a name together with a
> value.
> ** Note: A 2nd macro, NVL, in my implementation takes multiple arguments and
> creates a list of NameAndValue objects, i.e. NVL(x0,x1,x2) ===
> [NV(x0),NV(x1),NV(x3)]
> *** NV was kept to take only one argument, so additional arguments regarding
> output formatting could be supported in the future.
> * The returned NameAndValue objects can then be used flexibly to process
> further to e.g. create regex expressions, XML, test output, etc (or log/print
> directly if you like).
> * Both approaches by default create the same output when converted into a
> string, namely {code}NV(x) -> "x=$x"{code}
> * The current Groovy4 variety trades flexibility for performance (no
> intermediate NameAndValue objects are created), which is a good thing to have.
> * However it blocks both concepts from coexisting while using a concise, 2
> letter macro name.
> I therefore propose to change the naming convention of the Groovy 4 macros
> from NV* to SV*, since it
> # better expresses what happens ("stringify variable"), and
> # allows for the name & value pairs of the (more flexible/powerful) NV*
> macro and NameAndValue class to coexist with it.
> NameAndValue class:
> {code:java}
> class NameAndValue<T> {
> final String name
> final T val
> NameAndValue(String name, val) {
> this.name = name
> this.val = val
> }
> @Override
> String toString() {
> "$name=$val"
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
