• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

implicit narrowing conversions

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,
My Java text mentions the following as conditions that must hold for implicit narrowing conversions on assignment
  • the source is a constant expression of either byte,short,char or int
  • the destination is either byte,short or char
  • the value of the source is determined to be in the range of the destination at compile time


  • Then it goes on to say that no implicit narrowing conversions whatsoever are allowed on passing to method parameters.
    My first question is - why only allow types narrower than long ? Why not allow (for example) a constant double value that is in range ?
    My second question is - why not allow any narrowing at all for parameter passing ? My understanding is that parameters are really created only when methods are called at runtime, but if the rules above hold wouldn't it make sense to be consistent with the treatment of assignments as is the case in other operations ?
    I realize these questions are more "why's" than "how to's" but I would just like to understand some of the mechanics if possible.
    Thanks !
     
    David Fishman
    Greenhorn
    Posts: 18
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The same reply is also posted in a related thread from Jan 26, 2004 titled �Is this the right forum ?�
    Section 5.3 in the JLS indicates


    ...Method invocation conversions specifically do not include the implicit narrowing of integer constants which is part of assignment conversion. The designers of the Java programming language felt that including these implicit narrowing conversions would add additional complexity to the overloaded method matching resolution process...


    More details can be found in the JLS
     
    Ranch Hand
    Posts: 268
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You've hit the nail on the head with your question about "why not allow any narrowing at all, as long as it's within range?". The answer is, in two words: type safety. When you allow any narrowing at all, as long as it doesn't change the value, you've still broken type safety. Though you haven't changed the *value* of the variable, you've changed the possible *range* of values that variable can take on, and that can have subtle and surprising effects depending on the usage.
    For example, if I write a method:

    This method converts floats into extremes depending on whether they're less than 1 or not. Now if I could call this method with a double, and it returns a float so I can assign that return value to a double with no problem, look at this code:

    Most reasonable people would expect dExtreme to be either Double.MIN_VALUE or Double.MAX_VALUE.
    This is a pretty weak example because you can just look at the API for the extremify() method and sort it out, but if this procedure is happening in the middle of a method instead of with a call to an explicit, documented method, you could get thrown. Also, there are other cases for which I cannot conjure up examples at the moment that would lead to ambiguities in the language.
    Overall, the general rule should be absolutely no implicit narrowing period, and it would be fine with me if Java didn't have any exceptions to this rule. The exceptions they do allow have to do with very specific conversions for which no ambiguities can arise and for types such as byte that are truly "flat"...they are just strings of 0s and 1s and there is no connotations associated with the data...it is truly just "raw data", and when you can't make any assumptions about type, it frees you from certain restrictions.
    I know this is all very vague, but hopefully it gets you close enough to the path you can think it through and figure out the reasons from here on. I would, but it's been years since I dug into these issues and it's just not coming to as I sit and type.
    sev
     
    David Fishman
    Greenhorn
    Posts: 18
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Very insightful and clear !
    Thanks very much for this sever !
     
    reply
      Bookmark Topic Watch Topic
    • New Topic