Pourquoi ne pas toString () toujours automatiquement invoqué

Question

Alors, pourquoi n'est pas toujours invoqué tostring? Ceci est un exemple en utilisant l'API Android.

par exemple

@Override
public void onItemSelected(AdapterView<?> adapterView, View view,
        int position, long id) {
    Toast.makeText(this, adapterView, Toast.LENGTH_LONG).show();
}

ne compilera pas. Toutefois, si je change à

@Override
public void onItemSelected(AdapterView<?> adapterView, View view,
            int position, long id) {
    Toast.makeText(this, adapterView.toString(), Toast.LENGTH_LONG).show();
}

Il sera. Quelle est la différence réelle?

Answer 1

Que voulez-vous dire par toujours? toString() est juste une méthode qui retourne une représentation String de l'objet. Le Toast.makeText attend un paramètre String, mais dans le premier cas vous donner un objet de la classe AdapterView. Donc, il ne compilera pas:)

Answer 2

adapterView est pas String.

toString() n'est pas appelé automatiquement par le compilateur pour effectuer une distribution - qui porterait atteinte à la sécurité de type un peu. Seulement quand il y a un +"" par exemple, le compilateur appellera toString () automatiquement.

Answer 3

La seule situation dans laquelle toString () est inséré par le compilateur est en concaténation de chaînes.

Answer 4

En outre, cette

@Override
public void onItemSelected(AdapterView<?> adapterView, View view,
            int position, long id) {
    Toast.makeText(this, "" + adapterView, Toast.LENGTH_LONG).show();
}

compilera;)

Answer 5

Je ne sais pas l'API Android, mais AdapterView n'est pas en fait une sous-classe de CharSequence de sorte que vous devez appliquer toString ().

Answer 6

Je suppose que le deuxième paramètre de Toast.makeTest est de type String. Ensuite, en essayant de passer un paramètre de type AdapterView ne fonctionnera pas. toString () n'est jamais appelée automatiquement, sauf si concaténer Strings ( « » + adapterView fonctionnerait aussi bien, mais il est plus laid).

Answer 7

Le compilateur décide quelle méthode est nécessaire à partir du nom de la méthode et le nombre et les types de chaque argument fourni. Dans votre premier exemple, il recherche une méthode appelée maketext qui a un AdapterView comme second paramètre, et trouve pas (votre erreur de compilation vous aurait dit. Dans votre deuxième exemple, le second paramètre est une chaîne et du compilateur trouve la correspondance méthode. Notez que le compilateur ne peut pas trouver la méthode d'abord, puis faire entrer les paramètres, sinon nous ne pouvions pas avoir des méthodes surchargées.