Altering parameters of function

#21

@TW_Tones

I shall explain this code as you request.

[prefix<.myfn>(myFnArg)]

I want to restrict input to tiddlers beginning by a computed prefix. The computation is done by the .myfn function. This function has a parameter, and this parameter has to be added when calling .myfn. That parameter can be a constant string or the value of a procedure/variable or the result of a function.

That could be written as:

[prefix<.myfn>(a plain constant)]
[prefix<.myfn>(<myVariable>)]
[prefix<.myfn>(.myFunction)]

The difference between a plain constant and a function call is just the dot. Perhaps we should instead write:

[prefix<.myfn>(<.myFunction>)]

even if it is not similar to calling a function (it is similar to (re)calling a procedure/variable).

As for the syntax limitations: you would not be able to code:

[prefix<.myfn><.myFunction>[myArg01],[myArg02]]

and know wether myArg02 is the second argument of .myFunction or of .myfn. So you either limit .myFunction to a single argument or you add something in the syntax to allow for writing the two possibilites in a different way.

For instance we could write:

[prefix<.myfn>(<.myFunction>[myArg01],[myArg02])]

if myArg02 belongs to .myFunction. But if it belongs to .myfn we would write:

[prefix<.myfn>(<.myFunction>[myArg01]),[myArg02]]

Is that worth? Well, a good idea might make it worth while a poor would not. Readability is key. Consider a variation of syntax below for the same casres.

[prefix<.myfn><.myFunction>([myArg01],[myArg02])]
[prefix<.myfn><.myFunction>([myArg01]),[myArg02]]

I think this one is better than the previous one. And more OK with our present syntax. For this kind of things, we would surely benefit from having the possibilities to freely nesting [ and ] everywhere.

#22

I would still prefer;

  • I will do with it what I can.

Also plain language often requires a metaphor we all understand and avoiding abstract names like foo/bar/myArg01/.myFunction

Metaphors may include;

  • Preparing a name for cup of tea or coffee eg tea, milk with one (sugar)
  • Or just use informative names for what each function or parameter is to represent.
#23

Comment unrelated to the discussion: Good that you mentioned it. It seems that the :cascade and :then filter run prefixes are not mentioned among other prefixes in the Filter Expression tiddler. I’ll work on docs to include them and make them easier to discover. I never knew they existed, as I usually only consulted Filter Expression for a quick overview of prefixes.

Edit: I made PR with docs update: Improve docs on filter run prefixes by mateuszwilczek · Pull Request #7984 · Jermolene/TiddlyWiki5 (github.com)

2 Likes