New @function statement proposal

[bob2517]

Currently in ACSS there isn't a standard function syntax that provides a return value.

Ideally, you would be able to run any ACSS commands in a function, including embedded JS (using the existing run command syntax), and then simply return a value which can be substituted into any action command or target selector.

From a core development view, the core would be able to do this relatively easily, since the pause command effectively breaks out of a target selector and then rejoins after a certain time. So in theory we would just rejoin on the same command, check for any other functions to be run, rinse and repeat.

This would be more powerful than the SASS version, which only allows certain commands and isn't really much like a JS function. Plus it will work in real-time.

Syntax needs fleshing out for handling the return value, but the function itself could look like this:

@function nameOfFunction(par1, par2, etc.) {
    ... do stuff
    @return something;
}

At the moment, I use custom events for handling DRY code. I trigger those when needed. Inherited selector attributes are available inside triggered functions, scoped variables are available depending on where the triggered event is called. But none of that is probably very obvious in the docs. It all must look a bit unusual to the uninformed eye.

The other existing alternative in the core is making custom commands, but there are no return variables in custom commands, and these are more appropriate for writing in raw JS.

The @function command would allow a proper consolidated of techniques and provide an alternative to triggering events and getting a return value. A function is definitely where the average developer would look to, to do this, and it has implied rules that people are used to.

@functions will work on a global level (within the ACSS environment, obviously), but inherit the scope from which is it is called, therefore avoiding unnecessary redeclaration within a scope, which is the way @command works.

This is just a proposal at this point, but I can see a way to do it in the core, and it seems like a good next step.

[bob2517]

On a technical note, the internal "pause" command handling will need adjusting to cater for pausing within a function (it would essentially need a completely isolated "thread", held with the function itself (it's not really a thread though), which is different to the regular pause handling.

[bob2517]

This won't be in the next release, as it's a MEATY upgrade (that's a technical term and a new acronym - the letters can mean whatever you like).

[bob2517]

Factor in action command functions and general string concatenation.

[bob2517]

Closing - not sure this is needed. There may be a need for local JS function declaration, but even that isn't needed as you can put a run command into a custom event, and custom events can handle pause, etc. without any issue. Doing a special function statement would be tricky in the core if it needed to handle asynchronous logic or actions before returning a variable. It can be done in a custom event already without the need for parameters, as the core's var scopes mean that variables are around to be used.