Open ettersi opened 10 months ago
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
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
I thought this was by design? https://github.com/org-arl/fjage/pull/285#discussion_r1286457171
I believe the intention here was that NodeInfo.location
should be reduced to location
, but org.arl.unet.nodeinfo.NodeInfoParam.location
should not be reduced to location
.
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.
.ext.
ones) in java. If we go down this route, then we might want to consider making gateways throw an error if they receive parameters that they don't know about.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?
The second option is doable today without having to use qualified names with named params. Right?
No, because of this.
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
When you do e.g. node.get(new NamedParameter("location"))
, you get back a org.arl.unet.nodeinfo.NodeInfoParam.location
, and so rsp.get(new NamedParameter("location"))
on that is going to give you null
unless you have org.arl.unet.nodeinfo.NodeInfoParam.location
in your classpath.
My vote for making NamedParameter
work for fully-qualified parameter names, and essentially being equivalent to an Enum
parameter.
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
.