{"action":"created","issue":{"url":"https://api.github.com/repos/intendia-oss/autorest/issues/11","repository_url":"https://api.github.com/repos/intendia-oss/autorest","labels_url":"https://api.github.com/repos/intendia-oss/autorest/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/intendia-oss/autorest/issues/11/comments","events_url":"https://api.github.com/repos/intendia-oss/autorest/issues/11/events","html_url":"https://github.com/intendia-oss/autorest/pull/11","id":380211260,"node_id":"MDExOlB1bGxSZXF1ZXN0MjMwNDYzNzEy","number":11,"title":"Extend ResourceVisitor to hold parameters type information","user":{"login":"tedynaidenov","id":7092055,"node_id":"MDQ6VXNlcjcwOTIwNTU=","avatar_url":"https://avatars1.githubusercontent.com/u/7092055?v=4","gravatar_id":"","url":"https://api.github.com/users/tedynaidenov","html_url":"https://github.com/tedynaidenov","followers_url":"https://api.github.com/users/tedynaidenov/followers","following_url":"https://api.github.com/users/tedynaidenov/following{/other_user}","gists_url":"https://api.github.com/users/tedynaidenov/gists{/gist_id}","starred_url":"https://api.github.com/users/tedynaidenov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tedynaidenov/subscriptions","organizations_url":"https://api.github.com/users/tedynaidenov/orgs","repos_url":"https://api.github.com/users/tedynaidenov/repos","events_url":"https://api.github.com/users/tedynaidenov/events{/privacy}","received_events_url":"https://api.github.com/users/tedynaidenov/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-11-13T12:51:25Z","updated_at":"2018-11-20T16:30:58Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/intendia-oss/autorest/pulls/11","html_url":"https://github.com/intendia-oss/autorest/pull/11","diff_url":"https://github.com/intendia-oss/autorest/pull/11.diff","patch_url":"https://github.com/intendia-oss/autorest/pull/11.patch"},"body":"Using autorest with external serializer/deserializer framework might be painful since there is no type information associated with REST methods parameters and return result. Thus, selecting appropriate serializer/deserializer require additional efforts. The problems become even bigger when using generic parameters/return result since we have to select serializer/deserializer not only for the generic type but for the type parameters as well.\r\n\r\nProposed changes affect the annotation processor and ResourceVisitor builder.\r\n\r\n- Newly created Type class is a recursive structure, that allows to model generic types and their corresponding classes;\r\n\r\n- ResourceVisitor interface is extended to receive type information associated with each REST method parameter and method return result;\r\n\r\n- Annotation processor inspects each REST method parameter and return result type and generate corresponding code to build Type object for the parameter or methods return result;\r\n\r\n "},"comment":{"url":"https://api.github.com/repos/intendia-oss/autorest/issues/comments/440337489","html_url":"https://github.com/intendia-oss/autorest/pull/11#issuecomment-440337489","issue_url":"https://api.github.com/repos/intendia-oss/autorest/issues/11","id":440337489,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MDMzNzQ4OQ==","user":{"login":"ivmarkov","id":2607589,"node_id":"MDQ6VXNlcjI2MDc1ODk=","avatar_url":"https://avatars3.githubusercontent.com/u/2607589?v=4","gravatar_id":"","url":"https://api.github.com/users/ivmarkov","html_url":"https://github.com/ivmarkov","followers_url":"https://api.github.com/users/ivmarkov/followers","following_url":"https://api.github.com/users/ivmarkov/following{/other_user}","gists_url":"https://api.github.com/users/ivmarkov/gists{/gist_id}","starred_url":"https://api.github.com/users/ivmarkov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ivmarkov/subscriptions","organizations_url":"https://api.github.com/users/ivmarkov/orgs","repos_url":"https://api.github.com/users/ivmarkov/repos","events_url":"https://api.github.com/users/ivmarkov/events{/privacy}","received_events_url":"https://api.github.com/users/ivmarkov/received_events","type":"User","site_admin":false},"created_at":"2018-11-20T16:30:58Z","updated_at":"2018-11-20T16:30:58Z","author_association":"NONE","body":"> Thanks for the PR and for this detailed explanation! The long-term solution I have in mind is a bit different. But as it might take some time to implement it I might merge this PR as a temporary solution. This will also ensure that when the final solution is implemented, it will support this use case.\r\n\r\nWe would still be interested in an informal explanation of the long-term solution.\r\n>\r\n> Question about the container. I strongly recommend using the concept of a container to reduce casuistics. I also discourage callback, so the container solves 2 things, 1. asynchronicity and 2. high-level transport type (empty response or command, single element, and many elements or stream). I know that you can return a scalar value directly but this is a pretty bad idea. Or you can generalize as you suggest.\r\n\r\nI don't think we are suggesting not to use a container. We just don't want to use the RxJava containers, that's all. However, the change of the signature of the 'as' method is not because we want to use a different container, but because of other reasons, see below.\r\n\r\n> But, forcing you to differentiate the container might be more clear. Why just replace the second argument `Class<?> type` as `Type` is not enough? What container class are you using `Collection` and its subtypes?\r\n\r\nNo, we don't want to use \"collection\" and subtypes as the container. How would that work is actually beyond me. The main reason for using a container is because without it you can't really do an async call, can you? How would you be notified when the async result has arrived if you use a collection as a \"container\"? We'll just use our own, simple, custom container. User code wrapping it in an `Observable<>` is always possible btw.\r\n\r\nAs for whether replacing just the second argument as `Type` would work - yes, that would work. But you introduce an asymmetry this way - the container is represented with a `Class<?>` object, and the `Type` - which really is just the instantiated generic parameter of the container is a `Type`.  I.e.:\r\n- If I use e.g. `Observable<List<Map<MyKey, MyBean>>`, I need to artificially split the `Type` representing this into a `Class<?>` instance for `Observable<T>`, and into a `Type` instance for `List<Map<MyKey, MyBean>>` which is the instantiation of the generic variable `T` of your `Observable`.\r\n\r\nWhat gives?\r\n\r\n"}}
{"actor":{"display_login":"ivmarkov"}}