diamond operator

Discussion in 'Java' started by Roedy Green, Apr 4, 2012.

  1. Roedy Green

    Roedy Green Guest

    I was looking over the table of contents of a book about new features
    in Java 7 and came across a reference to the "diamond operator".

    It turns out to be simple, but one of the precious bits of Java
    syntactic sugar to make it terser.

    http://fahdshariff.blogspot.ca/2011/07/java-7-diamond-operator.html

    http://mindprod.com/book/9781849685627.html
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    When you were a child, if you did your own experiment
    to see if it was better to put to cocoa into your cup first
    or the hot milk first, then you likely have the programmer gene..
    Roedy Green, Apr 4, 2012
    #1
    1. Advertising

  2. Roedy Green

    Arne Vajhøj Guest

    On 4/3/2012 9:54 PM, Roedy Green wrote:
    > I was looking over the table of contents of a book about new features
    > in Java 7 and came across a reference to the "diamond operator".
    >
    > It turns out to be simple, but one of the precious bits of Java
    > syntactic sugar to make it terser.
    >
    > http://fahdshariff.blogspot.ca/2011/07/java-7-diamond-operator.html


    It is listed in the release notes:
    http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
    that link to the docs:

    http://docs.oracle.com/javase/7/doc...type-inference-generic-instance-creation.html

    It was probably also discussed here last summer when
    Java 7 was released.

    Arne
    Arne Vajhøj, Apr 4, 2012
    #2
    1. Advertising

  3. Silvio Bierman, Apr 4, 2012
    #3
  4. Roedy Green

    David Lamb Guest

    On 04/04/2012 7:12 AM, Silvio Bierman wrote:
    > On 04/04/2012 03:54 AM, Roedy Green wrote:
    >> I was looking over the table of contents of a book about new features
    >> in Java 7 and came across a reference to the "diamond operator".

    > With some exaggeration one might call it Java's type inferencing...


    Well, maybe, but from the little I recall of my programming language
    design classes, "real" type inferencing is a lot more powerful, so I
    think you ought to have said "much exaggeration."
    David Lamb, Apr 4, 2012
    #4
  5. On 04/04/2012 02:23 PM, David Lamb wrote:
    > On 04/04/2012 7:12 AM, Silvio Bierman wrote:
    >> On 04/04/2012 03:54 AM, Roedy Green wrote:
    >>> I was looking over the table of contents of a book about new features
    >>> in Java 7 and came across a reference to the "diamond operator".

    >> With some exaggeration one might call it Java's type inferencing...

    >
    > Well, maybe, but from the little I recall of my programming language
    > design classes, "real" type inferencing is a lot more powerful, so I
    > think you ought to have said "much exaggeration."


    Yep, it was an understatement.
    Silvio Bierman, Apr 4, 2012
    #5
  6. Roedy Green

    Jim Janney Guest

    Roedy Green <> writes:

    > I was looking over the table of contents of a book about new features
    > in Java 7 and came across a reference to the "diamond operator".
    >
    > It turns out to be simple, but one of the precious bits of Java
    > syntactic sugar to make it terser.
    >
    > http://fahdshariff.blogspot.ca/2011/07/java-7-diamond-operator.html
    >
    > http://mindprod.com/book/9781849685627.html


    This isn't wrong, but it fixes a problem I never knew I had. Any
    competent IDE will expand that for you anyway.

    --
    Jim Janney
    Jim Janney, Apr 4, 2012
    #6
  7. Roedy Green

    Arne Vajhøj Guest

    On 4/4/2012 8:23 AM, David Lamb wrote:
    > On 04/04/2012 7:12 AM, Silvio Bierman wrote:
    >> On 04/04/2012 03:54 AM, Roedy Green wrote:
    >>> I was looking over the table of contents of a book about new features
    >>> in Java 7 and came across a reference to the "diamond operator".

    >> With some exaggeration one might call it Java's type inferencing...

    >
    > Well, maybe, but from the little I recall of my programming language
    > design classes, "real" type inferencing is a lot more powerful, so I
    > think you ought to have said "much exaggeration."


    Give that the JLS says:

    <quote>
    If the type argument list to the class is empty — the diamond form "<>"
    — the type arguments of the class are inferred.
    </quote>

    then the usage of "type inference" can be defended.

    But it is certainly not what type inference is in languages
    like Scala etc..

    Arne
    Arne Vajhøj, Apr 5, 2012
    #7
  8. Roedy Green

    Lew Guest

    Jim Janney wrote:
    > Roedy Green writes:
    >> I was looking over the table of contents of a book about new features
    >> in Java 7 and came across a reference to the "diamond operator".
    >>
    >> It turns out to be simple, but one of the precious bits of Java
    >> syntactic sugar to make it terser.
    >>
    >> http://fahdshariff.blogspot.ca/2011/07/java-7-diamond-operator.html
    >>
    >> http://mindprod.com/book/9781849685627.html

    >
    > This isn't wrong, but it fixes a problem I never knew I had. Any
    > competent IDE will expand that for you anyway.


    It was added to Java to satisfy the whiners who were afraid they might strain a finger typing "Ctrl-V" or hitting ENTER on the IDE suggestion. Heaven help any of those folks should they ever have to actually work for a living..

    Not that I eschew the diamond operator myself now that it's here, but I wasn't clamoring for it beforehand.

    --
    Lew
    Diamonds are a girl's best friend. Dogs are a man's best friend. Diamonds cost more at first, but don't require feeding, walking, shots, neutering or spaying, veterinary or funeral bills, housebreaking, orreplacement expensesfor broken goods, and don't have litters. Still, I wish I had a dog.
    Lew, Apr 5, 2012
    #8
  9. Roedy Green

    Arivald Guest

    W dniu 2012-04-04 03:54, Roedy Green pisze:
    > I was looking over the table of contents of a book about new features
    > in Java 7 and came across a reference to the "diamond operator".
    >
    > It turns out to be simple, but one of the precious bits of Java
    > syntactic sugar to make it terser.
    >
    > http://fahdshariff.blogspot.ca/2011/07/java-7-diamond-operator.html
    >
    > http://mindprod.com/book/9781849685627.html


    It will be better to provide "auto" type detector, like in C++.
    For example, instead of:
    Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
    use:
    auto map = new HashMap<Integer, List<String>>();

    ....and "map" variable will be resolved at compile time to
    HashMap<Integer, List<String>>.

    This allow very handy construct, like:

    auto data = SomeService.getProviders();

    In this case type of "data" will be deducted from return type of
    SomeService.getProviders().

    This will save lot of typing. And save refactoring time in case if
    getProviders return type changes. And will auto-adapt to changes in
    libraries.

    --
    Arivald
    Arivald, Apr 5, 2012
    #9
  10. Roedy Green

    David Lamb Guest

    On 04/04/2012 7:41 PM, Arne Vajhøj wrote:
    > But it is certainly not what type inference is in languages
    > like Scala etc..

    Let alone Standard ML, where IIRC type inference is NP-hard.
    David Lamb, Apr 5, 2012
    #10
  11. Roedy Green

    Lew Guest

    Arivald wrote:
    > It will be better to provide "auto" type detector, like in C++.
    > For example, instead of:
    > Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
    > use:
    > auto map = new HashMap<Integer, List<String>>();
    >
    > ...and "map" variable will be resolved at compile time to
    > HashMap<Integer, List<String>>.
    >
    > This allow very handy construct, like:
    >
    > auto data = SomeService.getProviders();


    If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.

    > In this case type of "data" will be deducted [sic] from return type of
    > SomeService.getProviders().
    >
    > This will save lot of typing. And save refactoring time in case if


    It will save virtually no typing compared to current Java idioms.

    > getProviders return type changes. And will auto-adapt to changes in
    > libraries.


    This idea is incompatible with the current direction of type inference, which is in the other direction, and with Java's strong typing philosophy, andapparently the Powers That Be disagreed that your idea is better, as they didn't implement it.

    Your suggestion:
    > auto map = new HashMap<Integer, List<String>>();


    Current idiom:

    Map<Integer, List<String>> map = new HashMap<>();

    Not much difference in typing, certainly not enough to get your knickers ina twist over.

    Your suggestion:
    > auto data = SomeService.getProviders();

    which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.

    The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:

    Map<Integer, List<String>> data = getProviders();

    where the declaration of the method is something like:

    public Map<T, U> getProviders();

    Type inference tells 'getProviders()' what types 'T' and 'U' are.

    Your suggestion would break those.

    So it won't happen for those big reasons.

    You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):

    - they must not break Java (which yours does), at least not too much,
    - they must provide enough value to justify making any change at all (which yours doesn't).

    --
    Lew
    Lew, Apr 5, 2012
    #11
  12. Roedy Green

    David Lamb Guest

    On 04/04/2012 9:15 PM, Lew wrote:
    > Jim Janney wrote:
    >> Roedy Green writes:
    >>> I was looking over the table of contents of a book about new features
    >>> in Java 7 and came across a reference to the "diamond operator".

    >>
    >> This isn't wrong, but it fixes a problem I never knew I had. Any
    >> competent IDE will expand that for you anyway.

    >
    > It was added to Java to satisfy the whiners who were afraid they might strain a finger
    > typing "Ctrl-V" or hitting ENTER on the IDE suggestion. Heaven help

    any of those
    > folks should they ever have to actually work for a living.


    Overly harsh IMHO. If you ever change one of those places, you need to
    change them all, and having the language feature makes it easier and
    less error prone.
    David Lamb, Apr 5, 2012
    #12
  13. Roedy Green

    Arivald Guest

    W dniu 2012-04-05 20:34, Lew pisze:
    > Arivald wrote:
    >> > It will be better to provide "auto" type detector, like in C++.
    >> > For example, instead of:
    >> > Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
    >> > use:
    >> > auto map = new HashMap<Integer, List<String>>();
    >> >
    >> > ...and "map" variable will be resolved at compile time to
    >> > HashMap<Integer, List<String>>.
    >> >
    >> > This allow very handy construct, like:
    >> >
    >> > auto data = SomeService.getProviders();

    > If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.


    "auto" is (in C++) reserved word, part of language. It is resolved to
    concrete type at compile time, to type of first assigned value.


    >> > In this case type of "data" will be deducted [sic] from return type of
    >> > SomeService.getProviders().
    >> >
    >> > This will save lot of typing. And save refactoring time in case if

    > It will save virtually no typing compared to current Java idioms.
    >
    >> > getProviders return type changes. And will auto-adapt to changes in
    >> > libraries.

    > This idea is incompatible with the current direction of type inference, which is in the other direction, and with Java's strong typing philosophy,


    "auto" in C++ is strongly typed, at compile time.


    > and apparently the Powers That Be disagreed that your idea is better, as they didn't implement it.
    >
    > Your suggestion:
    >> > auto map = new HashMap<Integer, List<String>>();

    >
    > Current idiom:
    >
    > Map<Integer, List<String>> map = new HashMap<>();


    Current now... but apparently it is something new in Java 7. Till Java 7
    there was lot of redundant typing.

    Yet "diamond operator" does not allow to deduct type of variable from
    assigned function return value;


    > Not much difference in typing, certainly not enough to get your knickers in a twist over.
    >
    > Your suggestion:
    >> > auto data = SomeService.getProviders();

    > which you describe as "very handy", but violates strong typing,


    Again no, there is no typing violation. "auto" does not mean "any type",
    it mean "compiler, be nice and use type of first assigned variable". It
    is just syntactic sugar.


    > which requires that the compiler know the type of 'data'.


    No. Compiler know type returned by SomeService.getProviders(). And will
    use this type instead.

    Assuming that SomeService.getProviders() declare to return List<String>,
    this code:

    auto data = SomeService.getProviders();

    and this code:

    List<String> data = SomeService.getProviders();

    have same meaning. Both describe variable named "data" with type
    "List<String>".

    Note that compiler take type that function declare to return, not type
    of really returned object!


    >If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.


    If this method change its return type, code must be recompiled anyway,
    both with and without "auto". Currently Your code will stop compiling if
    new return type is incompatible with declared variable type.
    With "auto", compiler will adapt, and try compile subsequent source code
    with new type.

    >
    > The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
    >
    > Map<Integer, List<String>> data = getProviders();
    >
    > where the declaration of the method is something like:
    >
    > public Map<T, U> getProviders();
    >
    > Type inference tells 'getProviders()' what types 'T' and 'U' are.


    Interesting idea, I do not know that.

    But what You can do with this inferred types 'T' and 'U' in
    getProviders()? With Java generics not much. On the contrary to C++
    templates, You can not use T and U beyond Object type capabilities.
    Only Java reflection can save this construct, and make it a bit more useful.

    >
    > Your suggestion would break those.


    Not really. In this case compiler could issue error, due to not enough
    information. In this case programmer will be not allowed to use "auto".

    > So it won't happen for those big reasons.
    >
    > You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
    >
    > - they must not break Java (which yours does), at least not too much,


    I think there is no break. Type is exactly known at compile time, and
    will generate same bytecode.

    > - they must provide enough value to justify making any change at all (which yours doesn't).


    I respect Your opinion, but disagree. I found "auto" keyword very useful
    in C++. This is one of features I really miss in Java.

    By the way, I also miss few other things, like "typedef" keyword (for
    type aliasing) or templates. Both are great helpers for meta-programming.
    Java have "generics", which appears like C++ templates. But only
    appears, at first glance. Generics are no real templates, they just
    syntactic sugar that hide casting and allow a bit better compile time
    type checking. Nothing compared to real templates from C++. Very
    disappointing.
    Not mentioning security problems with Java generics...

    --
    Arivald
    Arivald, Apr 5, 2012
    #13
  14. Roedy Green

    Jim Janney Guest

    David Lamb <> writes:

    > On 04/04/2012 9:15 PM, Lew wrote:
    >> Jim Janney wrote:
    >>> Roedy Green writes:
    >>>> I was looking over the table of contents of a book about new features
    >>>> in Java 7 and came across a reference to the "diamond operator".
    >>>
    >>> This isn't wrong, but it fixes a problem I never knew I had. Any
    >>> competent IDE will expand that for you anyway.

    >>
    >> It was added to Java to satisfy the whiners who were afraid they might strain a finger
    >> typing "Ctrl-V" or hitting ENTER on the IDE suggestion. Heaven help

    > any of those
    >> folks should they ever have to actually work for a living.

    >
    > Overly harsh IMHO. If you ever change one of those places, you need to
    > change them all, and having the language feature makes it easier and
    > less error prone.


    There may be use cases where this is unequivocally a Good Thing; I've
    just never happened to run into one. Not sure I buy the error prone
    part, though: if it isn't correct it won't compile.

    I notice there's an Eclipse enhancement request to add a refactoring
    method to handle changing generic parameters:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=372568

    Seems a bit late at this point.

    --
    Jim Janney
    Jim Janney, Apr 5, 2012
    #14
  15. On 4/5/2012 1:34 PM, Lew wrote:
    > Arivald wrote:
    >> It will be better to provide "auto" type detector, like in C++. For
    >> example, instead of: Map<Integer, List<String>> map = new
    >> HashMap<Integer, List<String>>(); use: auto map = new
    >> HashMap<Integer, List<String>>();
    >>
    >> ...and "map" variable will be resolved at compile time to
    >> HashMap<Integer, List<String>>.
    >>
    >> This allow very handy construct, like:
    >>
    >> auto data = SomeService.getProviders();

    >
    > If 'auto' is a type, it should begin with an upper-case letter. If
    > it's not, you should explain what you intend.


    The `auto' comes from C++11, where the type of the variable is defined
    to be the type of the static value being assigned to it [1]. It is a lot
    more powerful in C++, where the language can define some obscene, opaque
    hidden types whose exact signatures are left unspecified by the
    specification. The largest set of these are the STL iterators, where
    iterators look like `std::map<A, B>::iterator', but, when expanded, tend
    to be a class with five or six template parameters and a name with way
    too many underscores to be sane. The following all refer to the same type:
    std::map<A, B>::iterator
    std::_Rb_tree<A, std::pair<A, B>, std::_Select1st<std::pair<A, B> >,
    std::less<A>, std::allocator<std::pair<const A, B> > >::iterator
    std::_Rb_tree_iterator<std::pair<A, B> >

    Given that A and B can be very long types themselves, it quickly becomes
    obscene just to write a simple for each loop, although C++11 also
    introduces a version of for-each loops that ameliorate this.

    The other reason for auto is lambda expressions: the type of a lambda
    expression is "a unique, unnamed class that has the following
    properties", much as the actual type of an anonymous inner class in Java
    is a unique, unnamed class which is only guaranteed to inherit from some
    method.

    > This idea is incompatible with the current direction of type
    > inference, which is in the other direction, and with Java's strong
    > typing philosophy, and apparently the Powers That Be disagreed that
    > your idea is better, as they didn't implement it.


    The C++11 auto keyword is still fully strongly typed. It's meaning is
    best described is "the compiler already knows the precise type of this
    variable, and I know what I can do with this type, but I don't want to
    spend 15 minutes fighting the compiler to figure out what the right type
    actually is." In C++, because of the magic of templates and typedefs,
    you can actually spend several minutes just trying to figure out how to
    tell the compiler the proper name of a type.

    In short, auto is not a matter of dynamic versus static typing, it's a
    matter of implicit versus explicit typing. C++ has a fairly complex type
    system that has lots of edge cases which happen surprisingly often,
    while Java's type system is cleaner, even if you throw in generics.
    Given also that I suspect templates are much more abused than Java's
    generics, I don't think the auto is as useful in Java as it is in C++.

    [1] If you really want to play language lawyer, it's the same type for
    the initializer expression as would be derived for template argument
    inference.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Apr 6, 2012
    #15
  16. Roedy Green

    Arne Vajhøj Guest

    On 4/5/2012 2:34 PM, Lew wrote:
    > Arivald wrote:
    >> It will be better to provide "auto" type detector, like in C++.
    >> For example, instead of:
    >> Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
    >> use:
    >> auto map = new HashMap<Integer, List<String>>();
    >>
    >> ...and "map" variable will be resolved at compile time to
    >> HashMap<Integer, List<String>>.
    >>
    >> This allow very handy construct, like:
    >>
    >> auto data = SomeService.getProviders();

    >
    > If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.


    Given that it is a C++ keyword, then ....

    >> In this case type of "data" will be deducted [sic] from return type of
    >> SomeService.getProviders().
    >>
    >> This will save lot of typing. And save refactoring time in case if

    >
    > It will save virtually no typing compared to current Java idioms.


    It will certainly save some typing.

    But saving typing is not really important.

    > Your suggestion:
    >> auto map = new HashMap<Integer, List<String>>();

    >
    > Current idiom:
    >
    > Map<Integer, List<String>> map = new HashMap<>();
    >
    > Not much difference in typing, certainly not enough to get your knickers in a twist over.
    >
    > Your suggestion:
    >> auto data = SomeService.getProviders();

    > which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.


    It is completely strong typed.

    The compiler just infer the type instead of the programmer typing it.

    It is available in lots of languages: C++, C#, Scala etc..

    > The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
    >
    > Map<Integer, List<String>> data = getProviders();
    >
    > where the declaration of the method is something like:
    >
    > public Map<T, U> getProviders();
    >
    > Type inference tells 'getProviders()' what types 'T' and 'U' are.
    >
    > Your suggestion would break those.


    No.

    That could still work.

    But you can obviously not infer on both L and R side.

    > You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
    >
    > - they must not break Java (which yours does), at least not too much,


    It will not break Java.

    C# got it in 3.0 and it did not break anything.

    > - they must provide enough value to justify making any change at all (which yours doesn't).


    That is more an opinion than a fact.

    Arne
    Arne Vajhøj, Apr 6, 2012
    #16
  17. Roedy Green

    Arne Vajhøj Guest

    On 4/5/2012 4:11 AM, Arivald wrote:
    > It will be better to provide "auto" type detector, like in C++.
    > For example, instead of:
    > Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
    > use:
    > auto map = new HashMap<Integer, List<String>>();
    >
    > ...and "map" variable will be resolved at compile time to
    > HashMap<Integer, List<String>>.
    >
    > This allow very handy construct, like:
    >
    > auto data = SomeService.getProviders();
    >
    > In this case type of "data" will be deducted from return type of
    > SomeService.getProviders().
    >
    > This will save lot of typing. And save refactoring time in case if
    > getProviders return type changes. And will auto-adapt to changes in
    > libraries.


    Scala does that. And so does most other new functional languages.

    But I am somewhat concerned about readability.

    In the example the reader may not remember what getProviders()
    return and therefor not know what type data is without looking
    it up.

    Arne
    Arne Vajhøj, Apr 6, 2012
    #17
  18. On 04/04/2012 06:23 PM, Jim Janney wrote:
    > Roedy Green<> writes:
    >
    >> I was looking over the table of contents of a book about new features
    >> in Java 7 and came across a reference to the "diamond operator".
    >>
    >> It turns out to be simple, but one of the precious bits of Java
    >> syntactic sugar to make it terser.
    >>
    >> http://fahdshariff.blogspot.ca/2011/07/java-7-diamond-operator.html
    >>
    >> http://mindprod.com/book/9781849685627.html

    >
    > This isn't wrong, but it fixes a problem I never knew I had. Any
    > competent IDE will expand that for you anyway.
    >


    IDE support is irrelevant in this discussion. Language syntax is not
    about typing.

    Code needs to be read and reasoned about. The better the syntax, the
    less reading effort needed to be able to reason. Java's redundant syntax
    in this respect is inefficient and the diamond operator takes away part
    of that.
    Silvio Bierman, Apr 6, 2012
    #18
  19. On 04/05/2012 08:34 PM, Lew wrote:
    >
    > This idea is incompatible with the current direction of type inference, which is in the other direction, and with Java's strong typing philosophy, and apparently the Powers That Be disagreed that your idea is better, as they didn't implement it.
    >


    Wrong if you are speaking about type inference in general. Languages
    like Scala and Haskell do it exactly this way and for good reasons.

    If you talk about type inference for Java, maybe.

    > Current idiom:
    >
    > Map<Integer, List<String>> map = new HashMap<>();
    >
    > Not much difference in typing, certainly not enough to get your knickers in a twist over.


    Typing is irrelevant. Laving out the left hand type increases
    readability by removing redundancy. In a different world your example
    could have been

    auto map = new Map<Integer,List<String>>();

    Any keyword as a replacement for auto would work.

    >
    > Your suggestion:
    >> auto data = SomeService.getProviders();

    > which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.
    >


    Wrong in two ways. What you describe is static typing, which is a
    specific form of strong typing.

    And Arivalds example conforms to static typing. The compiler can deduce
    the type of the right hand side expression and uses that is the static
    type for the variable. Again Scala and Haskell do it the same way.


    > The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
    >
    > Map<Integer, List<String>> data = getProviders();
    >
    > where the declaration of the method is something like:
    >
    > public Map<T, U> getProviders();
    >
    > Type inference tells 'getProviders()' what types 'T' and 'U' are.


    Type inference can work in two ways. It can either use an expected type
    to resolve the type of a (sub)expression but it can also use the type of
    a (sub)expression to deduce the type of a variable or function.

    What you describe is the first way using the expected type to determine
    what T and U should be. You can have it both ways without breaking
    stuff. In Scala you could have:

    val x1 : Set[Int] = new HashSet
    val x2 = new HashSet[Int]

    given a generic type HashSet taking a type parameter. The first one
    brings the x1's expected type into the new expression, the second one
    uses the type of the new expression to deduce the type of x2.



    >
    > Your suggestion would break those.


    Nope, it would not have to break any existing code.
    >
    > So it won't happen for those big reasons.
    >
    > You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
    >
    > - they must not break Java (which yours does), at least not too much,
    > - they must provide enough value to justify making any change at all (which yours doesn't).
    >



    I do not think it would be a worthwhile change to the Java language.
    Then again, the only reason why I value Java language changes is that
    they will sooner promote adoption of the JVM than create opposition.

    The JVM is our strategic choice. Java is our workhorse for maintaining
    legacy code. For everything new we have moved on to other languages,
    mainly Scala. Turning Java into something akin Scala is impossible and
    unnecessary.
    Silvio Bierman, Apr 6, 2012
    #19
  20. Roedy Green

    Thufir Guest

    On Fri, 06 Apr 2012 17:07:49 +0200, Silvio Bierman wrote:

    > Typing is irrelevant. Laving out the left hand type increases
    > readability by removing redundancy. In a different world your example
    > could have been
    >
    > auto map = new Map<Integer,List<String>>();
    >
    > Any keyword as a replacement for auto would work.


    While I'm familiar with neither Scala nor Haskell, that seems a bad
    idea. What happened to the idea of using a, for example, Ferrari
    interface on a Car instance? Sure, the object is a Car, but that Ferrari
    interface is used, well, not for convenience per se, but as a reminder
    that this Car is not *just* a Car.

    You're suggestion is completely contrary to that principle. While I
    appreciate that it's easier, I don't get the point.

    That being said, in Ruby you instantiate with:

    foo = Bar.new

    which is quite nice and simple.



    -Thufir
    Thufir, Apr 6, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jay Dean
    Replies:
    57
    Views:
    26,176
    Arne Vajhøj
    Dec 10, 2013
  2. Juha Nieminen
    Replies:
    1
    Views:
    341
    James Kanze
    Mar 2, 2009
  3. Chad Perrin
    Replies:
    11
    Views:
    233
    Chad Perrin
    Apr 16, 2007
  4. J. Romano

    binmode and the diamond operator

    J. Romano, Nov 8, 2003, in forum: Perl Misc
    Replies:
    6
    Views:
    182
    J. Romano
    Nov 17, 2003
  5. maryellen sniffen

    <> the Diamond Operator

    maryellen sniffen, Dec 31, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    119
    Anno Siegel
    Dec 31, 2004
Loading...

Share This Page