A more friendly assert for incorrect mut value

[grapho]

I believe the term "binding" makes more sense to most users as opposed to "path", because there are helpers which do accept "paths as strings"

This comes from a user I talked to, whom encountered the assert after doing {{mut 'isActive'}} by mistake and had trouble deciphering the meaning of the current assert error.

@wycats as the original author, do you have any thoughts/review for this?

[wycats]

@grapho I think "binding" might be a little jargon'y here. What did you find confusing about "path"?

[grapho]

@wycats path is not a bad term either, however i guess the format of the path is the potentially confusing part. I encountered a user that was attempting to do (mut 'foo.bar') which is a path represented as a sting.. much like how a link-to helper works or another similar helper that accept paths as strings.

I could update the assert to mentions that string values are not valid... but there was a concern by @locks that stating that could also be misleading as you cant really enumerate "all " the possible things that are not passable to mut

the assert does not explicity test for a string value.. it test if the value is a stream, so not sure the best way to go here.. if at all.

[taras]

There are several places in the code base where these are described as quoteless path. You can see all instances here.

It doesn't seem like a strong name because it describes them as the absence of something rather than describing the thing itself. LISP seems to use binding to describe these variable bits.

It would be great if we could come up with a name that specifically identifies these dynamic bits.

[pixelhandler]

I tend to like "path" - as it describes the object thing.prop, one reference that seems to support the concept of "path" is the JSON Patch spec describing what prop on an object is affected by an operation, see http://jsonpatch.com. (my vote is to stick with "path")

[homu]

☔ The latest upstream changes (presumably #14163) made this pull request unmergeable. Please resolve the merge conflicts.

[grapho]

Oh wow.. i forgot I actually made this a PR and not just an issue :p

If we are all lukewarm about this change i have no issue closing. I was considering newer users whom had questions on #slack not understanding what it meant

[locks]

Thanks for the discussion everyone, I'm closing as current art seems adequate.