Неявное преобразование от T до Опции [T] быть добавленным/созданным в Scala?

Обратите внимание, что вы можете использовать шаблон явный неявный , который позволит избежать путаницы и в то же время сохранить краткость кода.

То, что я имею в виду под явным неявным, скорее, чем прямое преобразование из T в Option [T] , вы можете преобразовать в объект-оболочку, который предоставляет средства для выполнения преобразование из T в Вариант [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)

... Я мог бы найти для него лучшее название, чем Optionable , но теперь вы можете написать такой код:

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

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

Я считаю, что этот способ полностью прозрачен и помогает в понимании написанного код - удачное удаление всех проверок на null.

Обратите внимание на T <: AnyRef - вы должны делать это неявное преобразование только для типов, которые допускают значения null ,

Общие рекомендации для неявных преобразований заключаются в следующем:

• Когда вам нужно добавить члены к типу (а-ля «открытые классы»; он же шаблон «прокачать мою библиотеку»), преобразовывайте в новый тип, который расширяет AnyRef и определяет только нужные вам элементы.
• Когда вам нужно «исправить» иерархию наследования. Таким образом, у вас есть некий тип A , который должен иметь подкласс B , но по какой-то причине этого не произошло. В этом случае вы можете определить неявное преобразование из A в B .

Это только случаи, когда уместно определить неявное преобразование . Любое другое преобразование в спешке сталкивается с проблемами безопасности типов и правильности

. Для T не имеет смысла расширять Option [T] , и, очевидно, целью преобразования является не просто добавление элементов. Таким образом, такое преобразование было бы нецелесообразным.

Может показаться, что это может сбивать с толку других разработчиков, когда они читают ваш код.

Как правило, кажется, неявное работает, чтобы помочь преобразовать из одного объекта другому, чтобы исключить запутанный код преобразования, который может загромождать код, но, если у меня есть какая-то переменная, и она каким-то образом становится Some , то это может показаться надоедливым.

Вы можете добавить некоторые код, показывающий его использование, чтобы увидеть, насколько он запутан.

Мне это нравится, за исключением того, что он может не работать для примитива T (который не может быть нулевым) . Я предполагаю, что неспециализированный универсальный шаблон всегда получает примитивы в штучной упаковке, так что, вероятно, все в порядке.