RejectedSoftware Forums

On Tue, 02 Oct 2012 13:50:24 +0200, mist wrote:

Does router for REST interfaces support overloaded methods interface? I was about to finish a patch that fixes this issue regarding automatic client generation, when suddenly understood that I have actually no idea if is supposed to work at all :) No 100% confidence from reading sources, need a dev comment.

To be more specific, I am more interested in practical overloading in form:
lalala method1(string id)
lalala method2()

..that should be possible as far as I can imagine because of different URLs, though more generic question still applies.

Am 10/2/2012 1:50 PM, schrieb mist:

Does router for REST interfaces support overloaded methods interface? I
was about to finish a patch that fixes this issue regarding automatic
client generation, when suddenly understood that I have actually no idea
if is supposed to work at all :) No 100% confidence from reading
sources, need a dev comment.

Not yet, although I always wanted to support that... The problems with
this begin with DMD though. It really needs some better reflection
capabilities, starting with traits(getParameterNames) and
traits(getParameterDefaultValues).

But the main problem is expressing types that are not known inside
vibe.http.rest in the generated string mixin. I'm currently using a hack
that fails as soon as a method has multiple overloads...

Am 10/2/2012 2:15 PM, schrieb mist:

On Tue, 02 Oct 2012 14:01:06 +0200, Sönke Ludwig wrote:

Am 10/2/2012 1:50 PM, schrieb mist:

Does router for REST interfaces support overloaded methods interface? I
was about to finish a patch that fixes this issue regarding automatic
client generation, when suddenly understood that I have actually no idea
if is supposed to work at all :) No 100% confidence from reading
sources, need a dev comment.

Not yet, although I always wanted to support that... The problems with
this begin with DMD though. It really needs some better reflection
capabilities, starting with traits(getParameterNames) and
traits(getParameterDefaultValues).

But the main problem is expressing types that are not known inside
vibe.http.rest in the generated string mixin. I'm currently using a hack
that fails as soon as a method has multiple overloads...

Well, ye, I have found that when was exploring client generation and I
think a have a fix for that. It involves custom fullyQualifiedTypename
template for non-functions and local import of module interface was
defined in. I was just about to write docs/tests for it and make a
proof-of-concept pull request when question about router has arisen.

I think I can try to pull this of with some help regarding questions
about router and overall design. "getParameterNames" feels like a pain,
but should be doable at least for specific required cases.

If you have a fix for that then the case you mentioned sould work fine.
Just overloading a method that yields the same URL will not work.

The current getParameterNames() solution works as long as two methods
have the same signature because it uses the function type's .stringof to
extract the parameters, whereas a __traits(getParameterNames) could work
on the declaration instead.

To work around it, I just introduced the possibility to add a _dummy
parameter that is ignored. By using different types, it is possible to
make the signatures unique - ugly but works for now.