I think you missed the point

Post #101,669 by JimWeirich 5/13/03 12:09:57 PM Reply	I think you missed the point The question is not how to represent null, but when extracting a integer from its boxed container, if the boxed container is missing (the reference is null), then should the result be zero (a reasonable default) or should it cause an exception (also a reasonable expectation). This has nothing to do with the historical representation of a null pointer as zero. Now, granted, the whole boxed primitive idea is a kludge to work around a lack of foresight in the original language design. (an aside: I wonder how much performance will be lost through this autoboxing technique, especially compared with eliminating primitives altogether. I suspect (without proof) that the no-primitives technique done right would have be faster overall). -- -- Jim Weirich jweirich@one.net [link\|http://w3.one.net/~jweirich\|http://w3.one.net/~jweirich] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #101,720 by tuberculosis 5/13/03 5:47:42 PM Reply	OK, maybe so Because now I'm trying to figure out how you put a null integer into the container in the first place. My guess is if autoboxing is implemented, then nobody will bother with using the wrapper classes directly (since they can't even be used for arithmetic now anyhow). IOW, you are never going to see this in brand new 1.5 code: Integer i = new Integer(5). List list = new ArrayList(); list.add(i); when you can do: List<int> list = new ArrayList<int>(); list.add(5); So how do you put a null value into this list? Is the problem this: List<Object> list = new ArrayList<Object>(); list.add(new Integer(5)); // do you need to do this or should the autoboxing make it an Integer? then the argument is int i = list.get(0); which should require a cast anyhow since the list type is Object. Hmmmm. I'm not seeing it. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #101,728 by JimWeirich 5/13/03 6:13:40 PM Reply	Re: OK, maybe so ToddBlanchard: [...] figure out how you put a null integer into the container in the first place. How about (stealing the example from the article) ... Map<String, Integer> m = new TreeMap<String, Integer>();\nint i = m.get("not_yet_in_map"); Should "i" be zero, or should there be a null pointer exception thrown? (remember that `get` returns a null pointer of the key doesn't exist). -- -- Jim Weirich jweirich@one.net [link\|http://w3.one.net/~jweirich\|http://w3.one.net/~jweirich] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #101,729 by tuberculosis 5/13/03 6:21:26 PM Reply	Well in this case I think a KeyNotFoundException should be thrown. This is just another case where Smalltalk's collection class protocols are vastly superior to J-crap. i := dict at: 'not_there' ifAbsent: [ 0 ]. For java I would propose something similar on Map. map.getValueIfAbsent('key_not_found',5); failure to use this should throw a KeyNotFoundException. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #101,736 by JimWeirich 5/13/03 7:16:46 PM Reply	Perhaps ... but ... Todd: For java I would propose [...] map.getValueIfAbsent('key_not_found',5); That's an interesting proposal ... but it still doesn't solve the basic question of unboxing nulls. But ... let's let the J-Heads worry about that. Ruby handles missing hash values a bit differently. If the key is not in the hash, you get a default value (which is typically nil, but can be something else). h = Hash.new\n h['not_there'] #=> nil\n\n g = Hash.new { 0 }\n g['not_there'] #=> 0\n\n j = Hash.new { fail "key not found" }\n j['not_there'] #=> Exception -- -- Jim Weirich jweirich@one.net [link\|http://w3.one.net/~jweirich\|http://w3.one.net/~jweirich] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #102,309 by tuberculosis 5/16/03 3:57:14 PM Reply	My point was it should be impossible to "box" null (and I think it probably is). So the problem ought not to exist. So the problem isn't how do you unbox null, its "how do you provide a mechanism for signaling and handling this case". I have found the requirement to provide a default "not found" value to be a useful bit of flypaper. OTOH, Java currently returns null from maps where the key is missing so I suppose they will decide that backwards compatibility is more important than better behvior. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police

Welcome to IWETHEY!