Methods for variables

[Taitava]

Sorry for the undescriptive title! Maybe I'll invent a better title later.

I was thinking about a solution for the {{tags}} variable's separator escaping issue. I got an idea, which can be expanded to more than separators.

I'll start directly with examples:

• {{tags}}->join(,)

• {{tags}}->count()

• {{file_name}}->length()

• {{file_name}}->or(A value that will be given when no file is active.)

• join(), count(), length() and or() are methods. This term is used in Object Oriented Programming (OOP).

• Methods need to be accessed with -> operator. I borrowed this from PHP programming language. A more common operator in other languages would have been ., but I wanted to have something that is is uncommon in shell commands, and for this reason a two characters long operator should do pretty well.

• join() takes one argument, a separator to join a list of values together.

• I'll tell more on the individual join(), count(), length() and ->or() methods later, by the time I plan on implementing them. join() and probably count() will be the first ones, others later.

This will allow even more methods to be created later.

Maybe some other parenthesis than ( and )?

• ->join{{,}} ?
• ->join((,)) ?
• ->join[[,]] ?

The issue with ( and ) is that as single character parenthesis, they are quite common and a user might want to use them in an argument for a method.

Escaping

So far I would think that methods should not do any escaping to what they return. This also means that future methods should be designed in a way, that they will not need escaping. But as this idea is very, very new to me, I might need to change my mind in the future.

Variables that return lists

Currently, the {{tags}} variable is the only variable that returns some kind of a list. Because a shell command is always text, all variables need to return text, too, so that they can be inserted into the shell command.

For list like variables, such as {{tags}}, the behavior will change so that the variable cannot be used in its base form: {{tags}}. Instead, the variable must be extended with a method call: {{tags}}->join(add your separator here), or {{tags}}->count(). Those methods return values that can be inserted into a shell command.

Also custom variables will some day support list type of variables.

[jeetsukumaran]

Following up from the the FR:

{{@<variable>, <function>, [<arg1>[, <arg2>[...]]}}

For e.g.:

cd {{yaml_value:workingdir}} && {{@yaml_value:command, join, ", "}}

Maybe function name needs to be quoted .

[Taitava]

I'd stil keep the current syntax for separating arguments with a colon : instead of a comma ,. And no double quotes. 🙂

So, my suggestion is:

cd {{yaml_value:workingdir}} && {{yaml_value:command}}->join{{, }}

Hmm, but actually the curly braces in join{{, }} can be confused to mean a variable structure. Even though {{, }} does not represent any variable per se, there's a theoretical possibility that someone would like to do e.g. {{yaml_value:command}}->join{{title}} to use the literal string title as a separator for values coming from {{yaml_value:command}}.

How about normal parenthese?

cd {{yaml_value:workingdir}} && {{yaml_value:command}}->join((, ))

I think this makes sense: ( and ) are typically used with functions/methods in many programming languages, so using them here makes join((, )) have the nice feeling that it really is a method. The parenthesis are doubled (so ((, )) instead of just (, )) to make it less likely to collide with shell syntax. And it follows the same line as {{variables}}: they use double curly braces, so double parenthesis for method calls is easy to remember (I hope),

TL;DR: My current decision is ->join((, )).

[jeetsukumaran]

I like it! Makes sense -- it fits, is intuitive, and does the job :)