Qute: shorter tag invocation

[FroMage]

Description

I found myself having lots of calls to tags that boiled down to:

 {#likeAlbum album=album user=user/}
 {#voteAlbum album=album user=user/}

And I wonder if we couldn't simplify those calls to:

 {#likeAlbum album user/}
 {#voteAlbum album user/}

That is: if we're passing a template parameter with no value (or no name, depending on how you look at it), we expand <ident> to <ident>=<ident>.

If I'm not mistaken, we can already currently pass a single parameter with no name, which ends up named as it, so we could expand the rules by saying that if the first parameter with no name is a single identifier (no dots, no complex expression) we make it available to the tag as both it and <ident>?

So, in our case, for a call of {#likeAlbum album user/} the album value would be bound to both it and album in the tag. I think that would make sense, no?

Implementation ideas

No response

[quarkus-bot]

/cc @mkouba

[mkouba]

In fact, you can currently access the user and album from the parent context, i.e. just call {#likeAlbum /}. But if we decide to disable this access by default then it would make sense.

[FroMage]

Well, if I can access stuff that is outside the current scope in a tag, then I don't even need parameters. That's very counter-intuitive to my scoped programming background where a function can only access the data it's passed directly.

[mkouba]

A user tag is not a function, it's more like a "named include directive". It makes sense for literal arguments, e.g. {#myTag optimized=true /} and if you want to simplify stuff, e.g. {#myTag name=album.artist.name /} and then in the tag then use just name.

[FroMage]

Well no, I strongly disagree: if we allow access to stuff that's outside we can't typecheck them. I don't think they should behave as named include directives.

[mkouba]

if we allow access to stuff that's outside we can't typecheck them.

First, type-checks are optional. Secondly, you can but you need to redefine the param declarations in the tag template - like you do in some vixen tags.

I don't think they should behave as named include directives.

But they do, for a long time... which does not mean we can't change it now. But it would be a breaking change and there is no easy way to detect that someone used it the current/old way.

[FroMage]

First, type-checks are optional. Secondly, you can but you need to redefine the param declarations in the tag template - like you do in some vixen tags.

They are optional, but if we turn them on we can't properly type-check if non-declared things are allowed to leak from the caller.

But they do, for a long time... which does not mean we can't change it now. But it would be a breaking change and there is no easy way to detect that someone used it the current/old way.

OK, but I'm not sure this usage is documented, is it? I certainly have never realised this was the case.

[mkouba]

They are optional, but if we turn them on we can't properly type-check if non-declared things are allowed to leak from the caller.

But you don't care about the "leaked" things... and all the variables that are used in the tag can be redeclared.

OK, but I'm not sure this usage is documented, is it? I certainly have never realised this was the case.

Well, quite a few other things are not documented either because (1) the ref guide would be 2x longer, (2) we don't have resources to document everything...

[FroMage]

I mean that if it's not documented, then it's never officially existed so nobody can possibly be using it, so we're free to change it ;)

But you don't care about the "leaked" things... and all the variables that are used in the tag can be redeclared.

I do, because they pollute my function, just like JS globals pollute local functions, they've been the bane of every language that has them. IIRC the last language that allowed the caller scope to leak into the callee was Emacs LISP: https://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Binding.html and yuck… ;)

Please, let's not do that :)

[mkouba]

I mean that if it's not documented, then it's never officially existed so nobody can possibly be using it, so we're free to change it ;)

Come on ;-)

I do, because they pollute my function,...

Your problem should be fixed in #22003. And it's not the same kind of problem because you don't specify the param on the call site which is not documented either... so you should not use it ;-)

[FroMage]

you don't specify the param on the call site which is not documented either... so you should not use it ;-)

HAHA. OK, good point :) But given that it was not documented, I could only rely on my intuition to think about how I should handle optional parameters.