-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle named parameters more consistently #292
Comments
groovy:000> rsp = new ParameterRsp(new ParameterReq())
===> ParameterRsp[]
groovy:000> rsp.set(new NamedParameter("spam.foo.bar"), 42, true)
===> null
groovy:000> rsp.get(new NamedParameter("bar"))
===> null failing is clearly a bug, if this works: groovy:000> rsp = new ParameterRsp(new ParameterReq())
===> ParameterRsp[]
groovy:000> rsp.set(new NamedParameter("foo.bar"), 42, true)
===> null
groovy:000> rsp.get(new NamedParameter("bar"))
===> 42 |
Something in fjage/src/main/java/org/arl/fjage/param/ParameterRsp.java Lines 151 to 161 in 0d4bc3e
or fjage/src/main/java/org/arl/fjage/param/NamedParameter.java Lines 82 to 92 in 0d4bc3e
|
I thought this was by design? #285 (comment) I believe the intention here was that |
Not quite by design, but a residue from some fix. As noted in the comment there: "We don't use qualified named parameters". That's where this problem comes from, since this issue deals with qualified parameter names, which aren't supported. We could, if we see a use case for them. Alternatively we can document that we don't support, and better yet, warn or throw an exception if someone defines a named parameter with qualified names? |
My objective here is to make it possible and reasonably easy to retrieve parameters from a Java gateway. AFAICT, there are two options to make this happen.
The second option sounds like less work to me, but maybe I'm missing something? |
The second option is doable today without having to use qualified names with named params. Right? |
No, because of this.
When you do e.g. |
My vote for making |
The current behaviour of named parameters is quite confusing.
This parameter lookup succeeds.
This parameter lookup also succeeds.
This one fails.
Finally, the last lookup would have succeeded if I had instead done this.
The difference between the last two lookups is particularly problematic because
someAgentId.get(new NamedParameter("bar"))
internally switches between the two depending on whether thebar
parameter is defined as a Java object somewhere in the classpath. Therefore, pretty harmless-looking Fjage code may produce different results without throwing an error depending on whether it is run usingjava XXX -cp A
orjava XXX -cp B
.The text was updated successfully, but these errors were encountered: