codeconsole commented on PR #16139:
URL: https://github.com/apache/grails-core/pull/16139#issuecomment-5287204828
You're right, and for a stronger reason than the syntax. `set` and `def`
aren't two spellings of one thing: `def` is a compile-time syntax tag that
declares a local, `set` is a runtime tag (`ApplicationTagLib.set`) that writes
into `pageScope`, or into `request`/`session`/`flash`/`application` via
`scope`, or pulls a `bean`. Swapping one for the other on this page didn't just
change how it was typed — it dropped the scope write. Nothing outside
`index.gsp` reads those names, so it happened to be behaviour-neutral here, but
that isn't something to do to the page every new application starts from.
So I've done your first option instead — `a794e2a`. `g:set` now takes a
`type`:
```
<g:set type="int" var="n" value="${2}"/>
```
```groovy
int n = Integer.cast(2)
invokeTag('set','g',1,['var':("n"),'value':(n)],-1)
```
The declaration is written first and the tag is then called with the
declared variable as its value, so the scope write still happens, `scope` still
decides where it goes, and an untyped `g:set` is unchanged. Covered by render
tests in `grails-gsp/plugin` against the real taglib: `${n}|${pageScope.n}`
gives `2|2`, and the same with `scope="request"`. The welcome page is back on
`g:set`.
`type` is only accepted alongside `value` — with a body or `bean` the value
is produced when the tag runs, so there's no expression to declare from; that's
rejected rather than quietly ignored.
On setting it to `Object`: that's the state that doesn't work. It compiles
until an operator is applied — a subscript is written into the class as `getAt`
and arithmetic as `plus`, and the class writer can't emit either against a
receiver of no known type. `${numControllers + numDomains}` is the failing
case, not a property read.
Your second option needed doing regardless: `<g:def type="int">` was
emitting `int.cast(...)`, and `Class.cast` on a primitive throws whatever it's
handed, so the page compiled and failed the moment it rendered. That's what
broke the forge jobs. Fixed in `43dcdc4` to cast through the wrapper, and the
tests render now instead of only compiling — which is why it reached CI in the
first place.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
