Scala: determine method result type for use in generics












4















In a third-party library there is a series of request classes, all of which derive from some common base class, which is generic and takes response class as a parameter:



abstract class AbstractRequest[ResponseType] {

def execute(): ResponseType
}

class UserList {…}
class UserListRequest extends AbstractRequest[UserList] {…}

class Avatar {…}
class AvatarRequest extends AbstractRequest[Avatar] {…}




I want to write some generic method that takes a request instance, executes it several times in some special ways and delegates processing of the responses to a function supplied in arguments:



def specialMultiExecute(request: Req)(responseHandler: Resp => Unit): Unit = …


— to be called like:



val myRequest: UserListRequest = …
specialMultiExecute(myRequest){ userList => … }


The problem is that I need to somehow specify Req and Resp types in the specialMultiExecute declaration. I tried the obvious approach:



def specialMultiExecute[Req <: AbstractRequest[Resp], Resp](request: Req)(responseHandler: Resp => Unit): Unit = …


— but Scala compiler fails to deduct generic argument types (an explicit specification like specialMultiExecute[UserListRequest, UserList](myRequest){ userList => … } is required).



In C++ in such case I could write a template function with a single template parameter Req, while making Resp to be determined as result type of the method Req::execute:



template<typename Req>
void specialMultiExecute(
Req request,
std::function<void (decltype(std::declval<Req>().execute()))> responseHandler
) {…}
//i.e. we use `decltype(std::declval<Req>().execute())` instead of Resp


Is there way to write something similar is Scala?



I mean something like (in Scala-like pseudocode):



def specialMultiExecute[Req <: AbstractRequest](request: Req)(responseHandler: ResultTypeOf(Req#execute) => Unit): Unit = …









share|improve this question























  • Do you need to know which sub type of AbstractRequest do you have, or are you fine wit only knowing which ResponseType you have?

    – Luis Miguel Mejía Suárez
    Nov 21 '18 at 20:11











  • @LuisMiguelMejíaSuárez, to say truth, it seems it's better for specialMultiExecute to know an exact subtype of AbstractRequest. (This may be non-obvious from the explanation above, but it's related to some unspecified dirty details on how specialMultiExecute internally works.) However, if I understand correctly, your first example covers this case (I'm now trying to read and understand how it works).

    – Sasha
    Nov 21 '18 at 21:23


















4















In a third-party library there is a series of request classes, all of which derive from some common base class, which is generic and takes response class as a parameter:



abstract class AbstractRequest[ResponseType] {

def execute(): ResponseType
}

class UserList {…}
class UserListRequest extends AbstractRequest[UserList] {…}

class Avatar {…}
class AvatarRequest extends AbstractRequest[Avatar] {…}




I want to write some generic method that takes a request instance, executes it several times in some special ways and delegates processing of the responses to a function supplied in arguments:



def specialMultiExecute(request: Req)(responseHandler: Resp => Unit): Unit = …


— to be called like:



val myRequest: UserListRequest = …
specialMultiExecute(myRequest){ userList => … }


The problem is that I need to somehow specify Req and Resp types in the specialMultiExecute declaration. I tried the obvious approach:



def specialMultiExecute[Req <: AbstractRequest[Resp], Resp](request: Req)(responseHandler: Resp => Unit): Unit = …


— but Scala compiler fails to deduct generic argument types (an explicit specification like specialMultiExecute[UserListRequest, UserList](myRequest){ userList => … } is required).



In C++ in such case I could write a template function with a single template parameter Req, while making Resp to be determined as result type of the method Req::execute:



template<typename Req>
void specialMultiExecute(
Req request,
std::function<void (decltype(std::declval<Req>().execute()))> responseHandler
) {…}
//i.e. we use `decltype(std::declval<Req>().execute())` instead of Resp


Is there way to write something similar is Scala?



I mean something like (in Scala-like pseudocode):



def specialMultiExecute[Req <: AbstractRequest](request: Req)(responseHandler: ResultTypeOf(Req#execute) => Unit): Unit = …









share|improve this question























  • Do you need to know which sub type of AbstractRequest do you have, or are you fine wit only knowing which ResponseType you have?

    – Luis Miguel Mejía Suárez
    Nov 21 '18 at 20:11











  • @LuisMiguelMejíaSuárez, to say truth, it seems it's better for specialMultiExecute to know an exact subtype of AbstractRequest. (This may be non-obvious from the explanation above, but it's related to some unspecified dirty details on how specialMultiExecute internally works.) However, if I understand correctly, your first example covers this case (I'm now trying to read and understand how it works).

    – Sasha
    Nov 21 '18 at 21:23
















4












4








4








In a third-party library there is a series of request classes, all of which derive from some common base class, which is generic and takes response class as a parameter:



abstract class AbstractRequest[ResponseType] {

def execute(): ResponseType
}

class UserList {…}
class UserListRequest extends AbstractRequest[UserList] {…}

class Avatar {…}
class AvatarRequest extends AbstractRequest[Avatar] {…}




I want to write some generic method that takes a request instance, executes it several times in some special ways and delegates processing of the responses to a function supplied in arguments:



def specialMultiExecute(request: Req)(responseHandler: Resp => Unit): Unit = …


— to be called like:



val myRequest: UserListRequest = …
specialMultiExecute(myRequest){ userList => … }


The problem is that I need to somehow specify Req and Resp types in the specialMultiExecute declaration. I tried the obvious approach:



def specialMultiExecute[Req <: AbstractRequest[Resp], Resp](request: Req)(responseHandler: Resp => Unit): Unit = …


— but Scala compiler fails to deduct generic argument types (an explicit specification like specialMultiExecute[UserListRequest, UserList](myRequest){ userList => … } is required).



In C++ in such case I could write a template function with a single template parameter Req, while making Resp to be determined as result type of the method Req::execute:



template<typename Req>
void specialMultiExecute(
Req request,
std::function<void (decltype(std::declval<Req>().execute()))> responseHandler
) {…}
//i.e. we use `decltype(std::declval<Req>().execute())` instead of Resp


Is there way to write something similar is Scala?



I mean something like (in Scala-like pseudocode):



def specialMultiExecute[Req <: AbstractRequest](request: Req)(responseHandler: ResultTypeOf(Req#execute) => Unit): Unit = …









share|improve this question














In a third-party library there is a series of request classes, all of which derive from some common base class, which is generic and takes response class as a parameter:



abstract class AbstractRequest[ResponseType] {

def execute(): ResponseType
}

class UserList {…}
class UserListRequest extends AbstractRequest[UserList] {…}

class Avatar {…}
class AvatarRequest extends AbstractRequest[Avatar] {…}




I want to write some generic method that takes a request instance, executes it several times in some special ways and delegates processing of the responses to a function supplied in arguments:



def specialMultiExecute(request: Req)(responseHandler: Resp => Unit): Unit = …


— to be called like:



val myRequest: UserListRequest = …
specialMultiExecute(myRequest){ userList => … }


The problem is that I need to somehow specify Req and Resp types in the specialMultiExecute declaration. I tried the obvious approach:



def specialMultiExecute[Req <: AbstractRequest[Resp], Resp](request: Req)(responseHandler: Resp => Unit): Unit = …


— but Scala compiler fails to deduct generic argument types (an explicit specification like specialMultiExecute[UserListRequest, UserList](myRequest){ userList => … } is required).



In C++ in such case I could write a template function with a single template parameter Req, while making Resp to be determined as result type of the method Req::execute:



template<typename Req>
void specialMultiExecute(
Req request,
std::function<void (decltype(std::declval<Req>().execute()))> responseHandler
) {…}
//i.e. we use `decltype(std::declval<Req>().execute())` instead of Resp


Is there way to write something similar is Scala?



I mean something like (in Scala-like pseudocode):



def specialMultiExecute[Req <: AbstractRequest](request: Req)(responseHandler: ResultTypeOf(Req#execute) => Unit): Unit = …






scala generics






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 21 '18 at 19:57









SashaSasha

1,5481528




1,5481528













  • Do you need to know which sub type of AbstractRequest do you have, or are you fine wit only knowing which ResponseType you have?

    – Luis Miguel Mejía Suárez
    Nov 21 '18 at 20:11











  • @LuisMiguelMejíaSuárez, to say truth, it seems it's better for specialMultiExecute to know an exact subtype of AbstractRequest. (This may be non-obvious from the explanation above, but it's related to some unspecified dirty details on how specialMultiExecute internally works.) However, if I understand correctly, your first example covers this case (I'm now trying to read and understand how it works).

    – Sasha
    Nov 21 '18 at 21:23





















  • Do you need to know which sub type of AbstractRequest do you have, or are you fine wit only knowing which ResponseType you have?

    – Luis Miguel Mejía Suárez
    Nov 21 '18 at 20:11











  • @LuisMiguelMejíaSuárez, to say truth, it seems it's better for specialMultiExecute to know an exact subtype of AbstractRequest. (This may be non-obvious from the explanation above, but it's related to some unspecified dirty details on how specialMultiExecute internally works.) However, if I understand correctly, your first example covers this case (I'm now trying to read and understand how it works).

    – Sasha
    Nov 21 '18 at 21:23



















Do you need to know which sub type of AbstractRequest do you have, or are you fine wit only knowing which ResponseType you have?

– Luis Miguel Mejía Suárez
Nov 21 '18 at 20:11





Do you need to know which sub type of AbstractRequest do you have, or are you fine wit only knowing which ResponseType you have?

– Luis Miguel Mejía Suárez
Nov 21 '18 at 20:11













@LuisMiguelMejíaSuárez, to say truth, it seems it's better for specialMultiExecute to know an exact subtype of AbstractRequest. (This may be non-obvious from the explanation above, but it's related to some unspecified dirty details on how specialMultiExecute internally works.) However, if I understand correctly, your first example covers this case (I'm now trying to read and understand how it works).

– Sasha
Nov 21 '18 at 21:23







@LuisMiguelMejíaSuárez, to say truth, it seems it's better for specialMultiExecute to know an exact subtype of AbstractRequest. (This may be non-obvious from the explanation above, but it's related to some unspecified dirty details on how specialMultiExecute internally works.) However, if I understand correctly, your first example covers this case (I'm now trying to read and understand how it works).

– Sasha
Nov 21 '18 at 21:23














1 Answer
1






active

oldest

votes


















3














It is a limitation of the type inference mechanism.
The simplest way to solve it is to use an implicit evidence that Req is a subtype of AbstractRequest[ResponseType].



Here is an example.



import scala.language.implicitConversions
import scala.reflect.runtime.universe.TypeTag

abstract class AbstractRequest[ResponseType] {
def execute(): ResponseType
}

final case class User(id: Int, name: String)
final case class House(id: Int, price: Int)

class UserListRequest extends AbstractRequest[List[User]] {
override def execute(): List[User] = List(User(id = 3, name = "Sasha"))
override def toString: String = "UserListRequest"
}

final class RequestWrapper[Req, Resp](val request: Req) extends AnyVal {
type ResponseType = Resp
}

implicit def request2wrapper[Req, Resp](request: Req)(implicit ev: Req <:< AbstractRequest[Resp]): RequestWrapper[Req, Resp] =
new RequestWrapper(request)

def specialMultiExecute[Req, Resp](wrapper: RequestWrapper[Req, Resp])
(responseHandler: wrapper.ResponseType => Unit)
(implicit ev: Req <:< AbstractRequest[Resp], TTReq: TypeTag[Req], TTResp: TypeTag[Resp]): Unit = {
val request: Req = wrapper.request
val executionResult: Resp = request.execute()
responseHandler(executionResult)
println(TTReq)
println(TTResp)
println(request)
}

specialMultiExecute(new UserListRequest())(println)
// List(User(3,Sasha))
// TypeTag[UserListRequest]
// TypeTag[List[User]]
// UserListRequest



Reference for <:<.
Reference for "Dependent types".




Edit



Te above code example was modified to allow identification of the concrete Request and Response types being used.






share|improve this answer


























  • Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

    – Sasha
    Nov 22 '18 at 12:37













  • Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 12:59











  • In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

    – Sasha
    Nov 22 '18 at 13:19






  • 1





    @Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 15:48











  • Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

    – Sasha
    Nov 22 '18 at 16:48











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53419634%2fscala-determine-method-result-type-for-use-in-generics%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














It is a limitation of the type inference mechanism.
The simplest way to solve it is to use an implicit evidence that Req is a subtype of AbstractRequest[ResponseType].



Here is an example.



import scala.language.implicitConversions
import scala.reflect.runtime.universe.TypeTag

abstract class AbstractRequest[ResponseType] {
def execute(): ResponseType
}

final case class User(id: Int, name: String)
final case class House(id: Int, price: Int)

class UserListRequest extends AbstractRequest[List[User]] {
override def execute(): List[User] = List(User(id = 3, name = "Sasha"))
override def toString: String = "UserListRequest"
}

final class RequestWrapper[Req, Resp](val request: Req) extends AnyVal {
type ResponseType = Resp
}

implicit def request2wrapper[Req, Resp](request: Req)(implicit ev: Req <:< AbstractRequest[Resp]): RequestWrapper[Req, Resp] =
new RequestWrapper(request)

def specialMultiExecute[Req, Resp](wrapper: RequestWrapper[Req, Resp])
(responseHandler: wrapper.ResponseType => Unit)
(implicit ev: Req <:< AbstractRequest[Resp], TTReq: TypeTag[Req], TTResp: TypeTag[Resp]): Unit = {
val request: Req = wrapper.request
val executionResult: Resp = request.execute()
responseHandler(executionResult)
println(TTReq)
println(TTResp)
println(request)
}

specialMultiExecute(new UserListRequest())(println)
// List(User(3,Sasha))
// TypeTag[UserListRequest]
// TypeTag[List[User]]
// UserListRequest



Reference for <:<.
Reference for "Dependent types".




Edit



Te above code example was modified to allow identification of the concrete Request and Response types being used.






share|improve this answer


























  • Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

    – Sasha
    Nov 22 '18 at 12:37













  • Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 12:59











  • In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

    – Sasha
    Nov 22 '18 at 13:19






  • 1





    @Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 15:48











  • Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

    – Sasha
    Nov 22 '18 at 16:48
















3














It is a limitation of the type inference mechanism.
The simplest way to solve it is to use an implicit evidence that Req is a subtype of AbstractRequest[ResponseType].



Here is an example.



import scala.language.implicitConversions
import scala.reflect.runtime.universe.TypeTag

abstract class AbstractRequest[ResponseType] {
def execute(): ResponseType
}

final case class User(id: Int, name: String)
final case class House(id: Int, price: Int)

class UserListRequest extends AbstractRequest[List[User]] {
override def execute(): List[User] = List(User(id = 3, name = "Sasha"))
override def toString: String = "UserListRequest"
}

final class RequestWrapper[Req, Resp](val request: Req) extends AnyVal {
type ResponseType = Resp
}

implicit def request2wrapper[Req, Resp](request: Req)(implicit ev: Req <:< AbstractRequest[Resp]): RequestWrapper[Req, Resp] =
new RequestWrapper(request)

def specialMultiExecute[Req, Resp](wrapper: RequestWrapper[Req, Resp])
(responseHandler: wrapper.ResponseType => Unit)
(implicit ev: Req <:< AbstractRequest[Resp], TTReq: TypeTag[Req], TTResp: TypeTag[Resp]): Unit = {
val request: Req = wrapper.request
val executionResult: Resp = request.execute()
responseHandler(executionResult)
println(TTReq)
println(TTResp)
println(request)
}

specialMultiExecute(new UserListRequest())(println)
// List(User(3,Sasha))
// TypeTag[UserListRequest]
// TypeTag[List[User]]
// UserListRequest



Reference for <:<.
Reference for "Dependent types".




Edit



Te above code example was modified to allow identification of the concrete Request and Response types being used.






share|improve this answer


























  • Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

    – Sasha
    Nov 22 '18 at 12:37













  • Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 12:59











  • In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

    – Sasha
    Nov 22 '18 at 13:19






  • 1





    @Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 15:48











  • Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

    – Sasha
    Nov 22 '18 at 16:48














3












3








3







It is a limitation of the type inference mechanism.
The simplest way to solve it is to use an implicit evidence that Req is a subtype of AbstractRequest[ResponseType].



Here is an example.



import scala.language.implicitConversions
import scala.reflect.runtime.universe.TypeTag

abstract class AbstractRequest[ResponseType] {
def execute(): ResponseType
}

final case class User(id: Int, name: String)
final case class House(id: Int, price: Int)

class UserListRequest extends AbstractRequest[List[User]] {
override def execute(): List[User] = List(User(id = 3, name = "Sasha"))
override def toString: String = "UserListRequest"
}

final class RequestWrapper[Req, Resp](val request: Req) extends AnyVal {
type ResponseType = Resp
}

implicit def request2wrapper[Req, Resp](request: Req)(implicit ev: Req <:< AbstractRequest[Resp]): RequestWrapper[Req, Resp] =
new RequestWrapper(request)

def specialMultiExecute[Req, Resp](wrapper: RequestWrapper[Req, Resp])
(responseHandler: wrapper.ResponseType => Unit)
(implicit ev: Req <:< AbstractRequest[Resp], TTReq: TypeTag[Req], TTResp: TypeTag[Resp]): Unit = {
val request: Req = wrapper.request
val executionResult: Resp = request.execute()
responseHandler(executionResult)
println(TTReq)
println(TTResp)
println(request)
}

specialMultiExecute(new UserListRequest())(println)
// List(User(3,Sasha))
// TypeTag[UserListRequest]
// TypeTag[List[User]]
// UserListRequest



Reference for <:<.
Reference for "Dependent types".




Edit



Te above code example was modified to allow identification of the concrete Request and Response types being used.






share|improve this answer















It is a limitation of the type inference mechanism.
The simplest way to solve it is to use an implicit evidence that Req is a subtype of AbstractRequest[ResponseType].



Here is an example.



import scala.language.implicitConversions
import scala.reflect.runtime.universe.TypeTag

abstract class AbstractRequest[ResponseType] {
def execute(): ResponseType
}

final case class User(id: Int, name: String)
final case class House(id: Int, price: Int)

class UserListRequest extends AbstractRequest[List[User]] {
override def execute(): List[User] = List(User(id = 3, name = "Sasha"))
override def toString: String = "UserListRequest"
}

final class RequestWrapper[Req, Resp](val request: Req) extends AnyVal {
type ResponseType = Resp
}

implicit def request2wrapper[Req, Resp](request: Req)(implicit ev: Req <:< AbstractRequest[Resp]): RequestWrapper[Req, Resp] =
new RequestWrapper(request)

def specialMultiExecute[Req, Resp](wrapper: RequestWrapper[Req, Resp])
(responseHandler: wrapper.ResponseType => Unit)
(implicit ev: Req <:< AbstractRequest[Resp], TTReq: TypeTag[Req], TTResp: TypeTag[Resp]): Unit = {
val request: Req = wrapper.request
val executionResult: Resp = request.execute()
responseHandler(executionResult)
println(TTReq)
println(TTResp)
println(request)
}

specialMultiExecute(new UserListRequest())(println)
// List(User(3,Sasha))
// TypeTag[UserListRequest]
// TypeTag[List[User]]
// UserListRequest



Reference for <:<.
Reference for "Dependent types".




Edit



Te above code example was modified to allow identification of the concrete Request and Response types being used.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 23 '18 at 14:18

























answered Nov 21 '18 at 20:26









Luis Miguel Mejía SuárezLuis Miguel Mejía Suárez

1,773721




1,773721













  • Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

    – Sasha
    Nov 22 '18 at 12:37













  • Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 12:59











  • In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

    – Sasha
    Nov 22 '18 at 13:19






  • 1





    @Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 15:48











  • Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

    – Sasha
    Nov 22 '18 at 16:48



















  • Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

    – Sasha
    Nov 22 '18 at 12:37













  • Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 12:59











  • In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

    – Sasha
    Nov 22 '18 at 13:19






  • 1





    @Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

    – Luis Miguel Mejía Suárez
    Nov 22 '18 at 15:48











  • Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

    – Sasha
    Nov 22 '18 at 16:48

















Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

– Sasha
Nov 22 '18 at 12:37







Although your answer doesn't answer my question directly (i.e. whether it is possible to get method result type in a way usable for generics), I got plenty other useful information from it. Therefore I accept it. (Additionally I found a way to make dirty internal details of specialMultiExecute to work without knowing exact Req type.)

– Sasha
Nov 22 '18 at 12:37















Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

– Luis Miguel Mejía Suárez
Nov 22 '18 at 12:59





Hi @Sasha, I'm glad it help you. I think the first code snippet provides you with all the information you need. (e.g. The exact type of Req & Resp), or am I missing something ?

– Luis Miguel Mejía Suárez
Nov 22 '18 at 12:59













In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

– Sasha
Nov 22 '18 at 13:19





In the first snippet Req[ResponseType] is AbstractRequest[List[User]], not UserListRequest. We can check that, for example, by println(scala.reflect.runtime.universe.typeOf[Req[ResponseType]]).

– Sasha
Nov 22 '18 at 13:19




1




1





@Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

– Luis Miguel Mejía Suárez
Nov 22 '18 at 15:48





@Sasha ah, you're right. The reason is that UserListRequest doesn't match the signature type Req[_] since it doesn't takes any type argument - my bad, sorry. I think I can fix it, and will update the answer once it is done.

– Luis Miguel Mejía Suárez
Nov 22 '18 at 15:48













Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

– Sasha
Nov 22 '18 at 16:48





Thanks. Actually, now the type of response still needs to be specified during a call, although it has moved from [UserListRequest, List[User]] to l: List[User] (but yeah, now we need to specify only Resp, not both Req and Resp). Anyway, as said before, I had found a way to make specialMultiExecute to work without knowing exact Req type, so now it's just for satisfying my thirst for research.

– Sasha
Nov 22 '18 at 16:48


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53419634%2fscala-determine-method-result-type-for-use-in-generics%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen