E14: Allow overloaded method access

[Joe Walker-3]

DWR currently isn't very smart about the way it handles overloaded methods, and basically we say "don't".
I think we could do better.

Issues:
- DWR generates one stub per server method signature, it ought to generate one per server method name. (This doesn't break things, just makes this less efficient)
- DWR generates stubs that have arguments rather than just passing on the arguments array to engine.js
- The server-side logic to select the best method does not take into account the incoming type information (one of the ways that dwrp is better than json - but we mostly ignore it!)

Joe.

[mikewse]

Being able to resolve the correct overloaded method would then rely on the client code using mapped classes for the parameters, right?

 

Best regards

Mike

---

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: den 13 juli 2008 00:06
To: users@...
Subject: [dwr-user] E14: Allow overloaded method access

DWR currently isn't very smart about the way it handles overloaded methods, and basically we say "don't".
I think we could do better.

Issues:
- DWR generates one stub per server method signature, it ought to generate one per server method name. (This doesn't break things, just makes this less efficient)
- DWR generates stubs that have arguments rather than just passing on the arguments array to engine.js
- The server-side logic to select the best method does not take into account the incoming type information (one of the ways that dwrp is better than json - but we mostly ignore it!)

Joe.

[Joe Walker-3]

So the algorithm goes like this:
- If there is only one method that matches both name and number of types, use that
- If we have a number of methods that have both the right name and number of types then:
  - For each method, attempt to convert the params for that method, if any of the parameters fails a test for converterManager.isConvertable the remove the method from the list of options
- If we have one remaining, use that. If we have more than one, warn and use the first, otherwise complain.

Maybe this is good enough?

Joe.

On Sat, Jul 12, 2008 at 11:52 PM, Mike Wilson <mikewse@...> wrote:

Being able to resolve the correct overloaded method would then rely on the client code using mapped classes for the parameters, right?

 

Best regards

Mike

---

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: den 13 juli 2008 00:06
To: users@...
Subject: [dwr-user] E14: Allow overloaded method access

DWR currently isn't very smart about the way it handles overloaded methods, and basically we say "don't".
I think we could do better.

Issues:
- DWR generates one stub per server method signature, it ought to generate one per server method name. (This doesn't break things, just makes this less efficient)
- DWR generates stubs that have arguments rather than just passing on the arguments array to engine.js
- The server-side logic to select the best method does not take into account the incoming type information (one of the ways that dwrp is better than json - but we mostly ignore it!)

Joe.

[mikewse]

As I wrote in E13 I think separate handling of class-mapped and non class-mapped parameters may help in doing the right thing. Here it is again:

• branch the inbound parameter conversion code in two phases (see 1 and 2):
• perform inbound conversion on all parameters that are class-mapped according to their mapped classes (1)
• now that we have successfully created these parameter objects, we can look through all matching methods and find one where our already available objects fulfill FormalArgumentClass.isAssignableFrom(parameterObject.getClass())
• hopefully this results in one method, and we can now take help of the formal argument types of the rest of the arguments to convert the remaining (not class-mapped) parameters (2)

I think this is doable and I agree that you should be the champion for this.

 

Best regards

Mike

---

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: den 13 juli 2008 11:52
To: users@...
Subject: Re: [dwr-user] E14: Allow overloaded method access

So the algorithm goes like this:
- If there is only one method that matches both name and number of types, use that
- If we have a number of methods that have both the right name and number of types then:
  - For each method, attempt to convert the params for that method, if any of the parameters fails a test for converterManager.isConvertable the remove the method from the list of options
- If we have one remaining, use that. If we have more than one, warn and use the first, otherwise complain.

Maybe this is good enough?

Joe.

On Sat, Jul 12, 2008 at 11:52 PM, Mike Wilson <mikewse@...> wrote:

Being able to resolve the correct overloaded method would then rely on the client code using mapped classes for the parameters, right?

 

Best regards

Mike

---

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: den 13 juli 2008 00:06
To: users@...
Subject: [dwr-user] E14: Allow overloaded method access

DWR currently isn't very smart about the way it handles overloaded methods, and basically we say "don't".
I think we could do better.

Issues:
- DWR generates one stub per server method signature, it ought to generate one per server method name. (This doesn't break things, just makes this less efficient)
- DWR generates stubs that have arguments rather than just passing on the arguments array to engine.js
- The server-side logic to select the best method does not take into account the incoming type information (one of the ways that dwrp is better than json - but we mostly ignore it!)

Joe.