Est-ce qu'une conversion implicite de T en Option [T] pourrait/devrait être ajoutée/créée dans Scala?

Question

Est-ce une opportunité pour rendre les choses un peu plus efficaces (pour le prorammer): Je trouve que ça devient un peu pénible d'avoir à emballer des choses en Some, par exemple. Some(5). Qu'en est-il quelque chose comme ceci:

implicit def T2OptionT(x : T) : Option[T] = if (x == null) None else Some(x) 

Answer 1

Vous risquez de perdre une certaine sécurité et de provoquer une confusion éventuelle. Par exemple:

val iThinkThisIsAList = 2 
    for (i <- iThinkThisIsAList) yield { i + 1 } 

I (pour une raison quelconque) pensais avoir une liste, et il n'a pas pris dans le compilateur quand j'itéré parce qu'il a été converti automatiquement à une option [Int] .

Je dois ajouter que je pense que cela est un grand implicite d'avoir explicitement importé, tout probablement pas un défaut global.

Answer 2

Il semblerait que cela pourrait être source de confusion pour les autres développeurs, car ils lisent votre code.

En général, il semble, implicit travaille pour aider cast d'un objet à un autre, pour découper le code de coulée confusion qui peut encombrer le code, mais, si j'ai une variable et il devient en quelque sorte un Some alors que cela semble être ennuyeux.

Vous pouvez mettre un peu de code montrant utilisé, pour voir comment il serait source de confusion.

Answer 3

Cela me semble bon, sauf qu'il ne fonctionne pas pour un T primitif (qui ne peut être nulle). Je suppose qu'un générique non spécialisé obtient toujours des primitives en boîte, alors c'est probablement très bien.

Answer 4

Notez que vous pouvez utiliser le modèle explicit implicit qui éviterait la confusion et de garder le code laconique en même temps.

Ce que je veux dire par implicite explicite est plutôt que d'avoir une conversion directe T-Option[T] vous pourriez avoir une conversion à un objet enveloppe qui fournit les moyens de faire la conversion T-Option[T].

class Optionable[T <: AnyRef](value: T) { 
    def toOption: Option[T] = if (value == null) None else Some(value) 
} 

implicit def anyRefToOptionable[T <: AnyRef](value: T) = new Optionable(value) 

... je pourrais trouver un meilleur nom pour elle que Optionable, mais maintenant vous pouvez écrire du code comme:

val x: String = "foo" 
x.toOption // Some("foo") 

val y: String = null 
x.toOption // None 

Je crois que cette façon est totalement transparente et contribue à la compréhension des le code écrit - éliminant tous les contrôles pour null d'une manière agréable.

Notez le T <: AnyRef - vous ne devez effectuer cette conversion implicite que pour les types qui acceptent les valeurs null, qui sont par définition des types de référence.

Answer 5

Les lignes directrices générales pour les conversions implicites sont les suivantes:

• Lorsque vous avez besoin d'ajouter des membres à un type (à la « classes ouvertes », alias le modèle « Pimp ma bibliothèque »), convertir en nouveau type qui étend AnyRef et qui définit uniquement les membres dont vous avez besoin.
• Lorsque vous devez "corriger" une hiérarchie d'héritage.Ainsi, vous avez un certain type A qui devrait avoir sous-classé B, mais n'a pas pour une raison quelconque. Dans ce cas, vous pouvez définir une conversion implicite de A à B.

Ce sont les seulement où il est approprié de définir une conversion implicite. Toute autre conversion se heurte à des problèmes de sécurité et d'exactitude.

Cela n'a vraiment aucun sens pour T d'étendre Option[T], et évidemment le but de la conversion n'est pas simplement l'ajout de membres. Ainsi, une telle conversion serait déconseillée.

Answer 6

Vous pouvez également essayer de surcharger la méthode:

def having(key:String) = having(key, None) 

def having(key:String, default:String) = having(key, Some(default)) 

def having(key: String, default: Option[String]=Option.empty) : Create = { 
    keys += ((key, default)) 
    this 
}