Tristan,
On 5/31/23 12:28, Tristan wrote:
If fetches already have the output type after the colon, then the
converter should not have the input type after the colon, i.e.
iif(str,str): bool => str
is confusing, because it looks like it returns a bool, ... I guess?
While this is mainly a feelings thing, I'd say that it is more
widespread (if not nowadays near-mainstream? not that this is
necessarily a good argument of course) to write it that way
Is it? In all the programming languages I use, the colon is followed by
the return type (which for iif is str). Of course the '=>' also implies
return type and now I'm seeing two return types there.
Another option might be listing the "implicit" parameter as a real
parameter:
iif(bool,str,str): str
This one feels quite unnatural to me; unless you're familiar with the
underlying implementation of many OOP systems and see this as some kind
of extension method definition, the fact that the first parameter is
implicitly passed seems (to me) like it's coming out of nowhere
I think it's pretty clear if you look at the usage in a config. Example
from my production config:
ssl_fc,iif(https,http)
That works like the pipeline operator in shell or various programming
languages. Effectively the 'ssl_fc' result acts as the first parameter,
it's just written a little differently. I also think it's the most
important parameter, because it represents the actual data that the
converter works with.
iif(str,str): bool => str
hides the type of the "important" parameter in the middle (and has the
colon = return type problem).
iif(str,str): str <= bool
at least has the parameter on an outer position, but the order is still
reversed from the config.
iif(bool,str,str): str
is reasonably similar to the config, but not identical
bool,iif(str,str): str
which I didn't mention before might possibly be the best choice?
Best regards
Tim Düsterhus
