Hi,
i just got some progress in my first D project and wanted to know if i made
some basic mistakes and what could have been done in an more elegant way.

I'm open for every advice i get.

The project is basicly a copy of javas jax-rs but in a very very early state :).
I know my Httprequest and Httpresponse classes aren't really existent but they weren't really my focus. just wanted to try out D s compiletime reflection.

http://www.dpaste.dzfl.pl/31ca9491

Have you seen vibe.d REST module? It does exactly that - abuses D reflection for REStful HTTP API generation.

code - https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/rest.d
example - https://github.com/rejectedsoftware/vibe.d/blob/master/examples/rest/source/app.d

yes i have seen it.
But i wanted to try it out my self. And thought it's a good project to learn D.

On Sunday, 1 December 2013 at 18:24:58 UTC, guest wrote:
> yes i have seen it.
> But i wanted to try it out my self. And thought it's a good project to learn D.

Well, you need to be a bit more precise about kind of feedback you want to get than :) It is pretty large topic to talk about.

just wanted to know if something in my code is really bad or could be solved in more elegant way. Basicly things which people with more experience in D see on their first view of my code.

On Sunday, 1 December 2013 at 18:37:25 UTC, guest wrote:
> just wanted to know if something in my code is really bad or could be solved in more elegant way. Basicly things which people with more experience in D see on their first view of my code.

The line splitting in HttpRequest can be simplified with Phobos functions. Look into std.array.split.

Not D specific, but you are nesting pretty deeply in my eyes. I would for example rewrite the run function:

  foreach(...) {
    if (foo) {
      bla
    }
  }

into

  foreach(...) {
    if (!foo) continue;
    bla
  }

In paramAssignment you could use scope(failure) instead of try-catch.

Design-wise your approach cannot be extended with new HTTP methods. For example, Subversion uses PROPFIND and REPORT.

You are using classes extensively, but I doubt that OO is the best paradigm here. It looks rather functional to me. Each request is mapped to a function call. Why grouping this into classes?

For my taste there is too much magic (string mixins), but it seems necessary for this annotation approach.

On Wednesday, 4 December 2013 at 09:09:56 UTC, qznc wrote:
> On Sunday, 1 December 2013 at 18:37:25 UTC, guest wrote:
>> just wanted to know if something in my code is really bad or could be solved in more elegant way. Basicly things which people with more experience in D see on their first view of my code.
>
> The line splitting in HttpRequest can be simplified with Phobos functions. Look into std.array.split.
>
> Not D specific, but you are nesting pretty deeply in my eyes. I would for example rewrite the run function:
>
>   foreach(...) {
>     if (foo) {
>       bla
>     }
>   }
>
> into
>
>   foreach(...) {
>     if (!foo) continue;
>     bla
>   }
>
> In paramAssignment you could use scope(failure) instead of try-catch.
>
> Design-wise your approach cannot be extended with new HTTP methods. For example, Subversion uses PROPFIND and REPORT.
>
> You are using classes extensively, but I doubt that OO is the best paradigm here. It looks rather functional to me. Each request is mapped to a function call. Why grouping this into classes?
>
> For my taste there is too much magic (string mixins), but it seems necessary for this annotation approach.

thx for your advice!
I changed the splitting and overviewd my nesting and the scope made
paramAssignment much cleaner (i really like that:) ).

About the design i'm not sure if a functional approche would be easier cause
I need to store all my annotated functions. The other problem i see with
a functional design are that i need to pass the request, response and all the
parameter to call the function.

To the magical part i really like that such kind of magic is possible but
I would be happy if someone has a better idea than string mixins.