I do not think your suggestion is a good idea, and I'd prefer not change it and 
remain the same. 


You problem comes from the semantics of the definition:
   void method(QueryWrapper querys, int p2);
For query parameter querys (type of QueryWrapper) do not mean one parameter, 
but many parameters based on it's structure, it a special grammar for POJO 
queries. So the client code can be:
   void method(int x, int y, int p2)
or 
   void method(int x, int y, int z, int p2)


When you add a new name for QueryWrapper, it equals to you add a parameter for 
   void method(int x, int y, int p2) to void method(int x, int y, int z, int p2)
and it's a change should be noticed that client should change the invocation 
code. 


Benefit for your suggestion is that users can add new parameters for an API, 
and I think this scenario is a CHANGE, and should change client code, but not 
adapt to it.


And if you use parameter name to handle this, their will cause conflicts. For 
example, add an x for this method:
   void method(QueryWrapper querys, int x, int y);


And We need to consider other problems like name in @RequestParam("name1")  is 
different with parameter name. 


In conclusion, I prefer not to handle this scenario. 


------------------ ???????? ------------------
??????: "zzzwjm"<zzz...@gmail.com>;
????????: 2019??1??18??(??????) ????0:17
??????: "dev@servicecomb.apache.org"<dev@servicecomb.apache.org>;

????: Re: [discuss] change mechanism of java chassis POJO consumerparamters 
mapping



java8 support present interface method parameter name
need to add compile argument, not debug option

?? 2019??1??17??????????Willem Jiang <willem.ji...@gmail.com> ??????

> Java compile will remove the parameters name by default. We faced the
> same problem in CXF simple frontend.
> The solution could be enable the debug option in the compiler or add
> annotation to the parameters.
>
> If we decide to setting the option on the compiler, we should not only
> throw exception in the runtime, but also document it.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: ????willem
>
> On Thu, Jan 17, 2019 at 5:23 PM wjm wjm <zzz...@gmail.com> wrote:
> >
> > Scenes??
> > 1.producer is springMVC dev mode
> >   class QueryWrapper {
> >     int x;
> >     int y;
> >   }
> >   void method(QueryWrapper querys, int p2);
> >
> >   will produce swagger operation, have 3 parameters: x, y, p2
> >
> > 2.consumer is POJO dev mode, declare a interface:
> >   interface TestIntf {
> >     void method(int x, int y, int p2);
> >   }
> >   until now, everything is ok.
> >
> > 3.producer upgrade
> >   class QueryWrapper {
> >     int x;
> >     int y;
> >     int z;
> >   }
> >   will produce swagger operation, have 4 parameters: x,y,z,p2
> >
> >   in this time, old POJO consumers will have problems:
> >     assign x to x, y to y, p2 to z
> >   that's because we map parameters by their index
> >
> > to resolve the problem:
> >   we need to map parameters by their name
> >   this require customers change their compile argument in pom.xml to
> allow
> > interface present method parameter name
> >   if did not add compile argument, SDK can throw exception, and print how
> > to add the compile argument.
> >
> >   any idea?
>

Reply via email to