Argumenttyp von map.get(.)

[Marco13]

Hi

Warum akzeptiert eine Map, die mit Generics getypt ist, bei der get-Methode immernoch ein "Object" als Schlüssel? ???:L

import java.util.*;

class Foo
{
}

class TypeTest3
{
    private Map<Foo, String> map = new HashMap<Foo, String>();

    public static void main(String args[])
    {
        new TypeTest3();
    }

    public TypeTest3()
    {
        map.put(new Foo(), "Foo");
        System.out.println(map.get(1));
    }
}

Bei "put" (und dem Rückgabewert von "get") ist doch auch die Typsicherheit gewährleistet, warum nicht beim Argument?


bye

 

[mikachu]

keine ahnung, aber es kommt nicht das gewünschte ergebnis raus, wenn was anderes nimmst

   public static void main( String[] args )
   {
      class Foo
      {
      }
      Foo bar = new Foo();
      Map<Foo, String> map = new HashMap<Foo, String>();
      map.put( bar, "B" );
      System.out.println( map.get( bar ) );  // "B"
      System.out.println( map.get( 0 ) ); //  null
  }

 

[Gelöschtes Mitglied 5909]

du kannst doch net auf den index zugreifen was du da oben machen willst... wenn du drüber iterieren willst nimmste n keyset, ansonsten musste halt den key nehmen und nicht einfach ne zahl... kannst zwar auch ne zahl als key nehmen, is aber kein index

 

[Gelöschtes Mitglied 8197]

Ein kurzer Blick in die Javadoc von Map zeigt, dass get() nicht <K>, sondern Object als Argument erwartet. Ein paar weitere Methoden übrigens auch.
Damit dürfte die Frage zumindest aus technischer Sicht beantwortet sein, der Sinn dabei scheint mir auch ein wenig seltsam.

aber es kommt nicht das gewünschte ergebnis raus, wenn was anderes nimmst

Es kommt immer null, wenn der Schlüssel nicht vorhanden ist. Hast du etwas anderes erwartet?

 

[bygones]

du kannst doch net auf den index zugreifen was du da oben machen willst... wenn du drüber iterieren willst nimmste n keyset, ansonsten musste halt den key nehmen und nicht einfach ne zahl... kannst zwar auch ne zahl als key nehmen, is aber kein index

java 1.5 kennt das sog. autoboxing, d.h. primitive datentypen wie int werden zu Objekten automatisch... daher ist 1 nicht ein zugriff auf einen index, sondern steht fuer das Integer Objekt 1.

wegen dem get... ist man konsequent so stimmt es, es sollten so und so nur Typ vom Schluessel akzeptiert werden... ergebnisorientiert isses aber wurscht, die Typsicherheit ist nicht gefaehrtet...

 

[SlaterB]

>die Typsicherheit ist nicht gefaehrtet...

??

siehe dir doch das Beispiel oben an,
wenn dort der Fehler gemeldet würde, dass Integer der falsche Typ ist,
dann könnte man erkennen, dass man da ein ganz falsches Objekt eingesetzt hat,
dass man eigentlich das Foo-Objekt braucht,

wofür ist den Generics gut wenn nicht für diesen Check?
nur um Casting zu sparen?

 

[bygones]

wo ist da bitte die Typsicherheit gefaehrtet ?

die Typsicherheit garantiert dir, dass zur laufzeit kein fehler durch falsche Typen in deiner Map passieren.

Allein durch eine Leseaktion (also das get) wird diese Garantie nicht unterlaufen.

Ich sagte ja... wenn man konsequent ist stimmt das, es sollte einen Fehler geben (und ich bin auch der meinung dass dies der richtige weg ware). Aber die Typsicherheit der Map ist hier nicht verletzt !!

 

[SlaterB]

wie sollte auch ein Laufeitfehler passieren, wenn eh Object verlangt wird,
dass ist doch bei Listen oder eigenen Klassen genauso,

wärst du auch zufrieden, wenn man in eine ArrayList<String> beliebige Objekte einfügen könnte?
eine Hälfte des ganzen Spasses ist das Einfügen nur der richtigen Objekte,
das geht hier komplett nicht,

(edit: naja, nicht ganz das 'einfügen', aber jedenfalls geht ein Teil nicht )

welches formale Kriterium nun erfüllt ist oder nicht..
es geht doch um die praktische Verwendung..

 

[bygones]

wärst du auch zufrieden, wenn man in eine ArrayList<String> beliebige Objekte einfügen könnte?
eine Hälfte des ganzen Spasses ist das Einfügen nur der richtigen Objekte,
das geht hier komplett nicht,

wir reden hier NICHT ueber einfuegen... also ueber put

wir reden hier ueber lesen... get....


nochmal:

es ist nicht konsequent und das stimmt - aber gegen die Typsicherheit spricht es in keiner weise !

 

[Gelöschtes Mitglied 5909]

java 1.5 kennt das sog. autoboxing, d.h. primitive datentypen wie int werden zu Objekten automatisch... daher ist 1 nicht ein zugriff auf einen index, sondern steht fuer das Integer Objekt 1.

das is mir bekannt, nur macht er ja kein Integer rein...

 

[bygones]

java 1.5 kennt das sog. autoboxing, d.h. primitive datentypen wie int werden zu Objekten automatisch... daher ist 1 nicht ein zugriff auf einen index, sondern steht fuer das Integer Objekt 1.

das is mir bekannt, nur macht er ja kein Integer rein...

dann ist das dir nicht bekannt ;-)

map.get(1) = map.get(new Integer(1));

ist das selbe... java 1.5 wandelt dir die primitiven typen wie int in die Wrapper objekte wie Integer um

 

[Marco13]

Erstmal vorneweg: Das Autoboxing ist (mir) bekannt (und in diesem Fall "Absicht", weil der Fahler genau so bei mir aufgetreten ist). Das "1" sollte also kein Index sein (dass das bei einer Map keinen Sinn macht, ist mir AUCH bekannt), sondern nur ein beliebiger Key. Man hätte auch
map.get("I am a string");
nehmen können - das "sollte" auch nicht funktionieren, tut es aber.

Die Typsicherheit ist zwar nicht wirklich gefährtdet, weil man ja immer den "richtigen" Typ zurückbekommt, nur leuchtet mir nicht ein, warum man das "get" nicht auch typt. Was spricht denn dagegen? Ein Argument könnte jetzt sein: "Weil man ja vielleicht auch mal einen anderen Typ als Key verwenden will, und dann akzeptiert, dass da vielleicht 'null' zurückkommt". Das Problem ist aber, dass das Wort "vielleicht" bei diesem Argument überflüssig (und das Argument damit hinfällig) ist - schließlich ist "put" ja getypt.

Mal ganz plakativ: Wenn ich eine Map<K,V> schreiben würde, dann würde ich das Argument von "get" streng auf "K" typen, weil alles andere imho keinen Sinn macht.

 

[bygones]

@marco:

das warum wirst du wahr. nur von den entwicklern selber bekommen (schonmal bei sun direkt gesucht ob da was zu finden ist ?)... ich weiss keinen logischn grund warum man es so gemacht hat....