aspose file tools*
The moose likes Java in General and the fly likes How to force inferring in this code? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "How to force inferring in this code?" Watch "How to force inferring in this code?" New topic
Author

How to force inferring in this code?

Andrew Gaydenko
Greenhorn

Joined: Jul 05, 2008
Posts: 10

I have a class abstracting "result":



Is it possible to modify the class to force commented out string



to work? I gess this type information



is sufficient for compiler to infer.
Jonas Isberg
Ranch Hand

Joined: Mar 18, 2003
Posts: 118
Did you try? What did you try? What happened?

If you ShowSomeEffort more people will take an interest in your problems.
Andrew Gaydenko
Greenhorn

Joined: Jul 05, 2008
Posts: 10

Jonas Isberg wrote:Did you try? What did you try? What happened?

If you ShowSomeEffort more people will take an interest in your problems.


Sorry, I don't understand your post. The first topic message contains all answers to your questions. OK. answers are:

- yes, I have tried
- I have tried the way the class is sketched
- inference doesn't work the way I'd want
Jonas Isberg
Ranch Hand

Joined: Mar 18, 2003
Posts: 118
Andrew Gaydenko wrote:Sorry, I don't understand your post.

Let me try to be more clear then.

From my understanding your problem is this:
  • You have some code that you want to introduce some change in.
  • Your suggested change wont work, but you believe it should have worked.

  • You donnot say exactly what problem you have with your suggested change. Just saying ItDoesntWorkIsUseless.

    Will it compile with your change? Will it throw a RuntimeException?

    If you TellTheDetails and let us know what you have tried and with what result, you are much more likely to get help.

    Many, if not most of us, think it is much better to gently prod you in the right direction so you solve the problem yourself,
    rather then just hand you the solution.

    If I still do not make myself clear, the links I have provided above will most likely explain my point even better, please try them.
    Andrew Gaydenko
    Greenhorn

    Joined: Jul 05, 2008
    Posts: 10

    Jonas Isberg wrote:
  • You have some code that you want to introduce some change in.


  • Yes. It is my own sketch.


    Jonas Isberg wrote:
  • Your suggested change wont work, but you believe it should have worked.


  • I didn't suggest any change, rather I ask readers for this change.

    Jonas Isberg wrote:You donnot say exactly what problem you have with your suggested change.
    I have said absolutely exactly - with code fragments (it isn't possible to be more elaborate ) - about the aim. Please look at the first post. At the end you will find two single-string snippets - with (working case) and without (not compilable call - inference doesn't work the way I expect) type parameter.
    Martin Vajsar
    Sheriff

    Joined: Aug 22, 2010
    Posts: 3611
        
      60

    I think this question is quite clearly asked, actually.

    The problem seems to be that you're mixing interfaces and implementations in your code. When you declare the list variable as List<String> instead of ArrayList<String>, the line which didn't work will be compiled without problems. You'll start having issues with line 65 instead, but again, declare r3 as Res<List<String>>, not ArrayList. You should declare variables using interfaces and not implementations, and this is just one of many good reasons to do so.
    Andrew Gaydenko
    Greenhorn

    Joined: Jul 05, 2008
    Posts: 10

    Martin Vajsar wrote:You should declare variables using interfaces and not implementations, and this is just one of many good reasons to do so.
    Yes, of course. It was just use case example. In other more simple words, we have:




    I see, 'B extends A' doesn't mean 'Res<B> extends Res<A>' (and it is most unexpected feature of Java generics, if I understand correctly). But I have guessed explicit parameter in res2 declaration is sufficient to infer type parameter in 'Res.ok(new B())' method call.

    Martin Vajsar
    Sheriff

    Joined: Aug 22, 2010
    Posts: 3611
        
      60

    Andrew Gaydenko wrote:I see, 'B extends A' doesn't mean 'Res<B> extends Res<A>' (and it is most unexpected feature of Java generics, if I understand correctly).

    Yes, this is actually the problem in our case.

    But I have guessed explicit parameter in res2 declaration is sufficient to infer type parameter in 'Res.ok(new B())' method call.

    I'm not sure how, if or when the expected return type is considered in the type inferring mechanism, however, in this case, the type can (and is) fully inferred from the method parameters alone. The resulting type is then incompatible with the variable, as a consequence of the previous point.

    By specifying the type in the method call, you're passing the List<String> where ArrayList<String> is expected, and these types are compatible. So no compiler warning here.

    I'm still on Java 6, but I believe Java 7 hasn't changed these rules, except of the diamond operator, which doesn't apply here.
    Andrew Gaydenko
    Greenhorn

    Joined: Jul 05, 2008
    Posts: 10

    Martin Vajsar wrote:I'm not sure how
    I'm next here. It seems to be impossible. And it works in Scala

    In particular, 'val v1: Seq[A] = ok(new B)' illustrates my intention (the string is compilable as expected).
    OK, will type in a little more characters in Java code...
    Andrew Gaydenko
    Greenhorn

    Joined: Jul 05, 2008
    Posts: 10

    It seems I have found the way - look at constructor and ok() methods definitions:

    All compiles works as expected. Look at r2 assignments: we can freely omit type parameters in Res.ok() method calls - the aim of this topic
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: How to force inferring in this code?