конечно. У Akka есть отличный пример этого в отношении своих актеров. Когда ты внутри актерского receive метод, вы можете отправить сообщение другому актеру. Когда вы это сделаете, Akka будет связывать (по умолчанию) текущий актер как sender сообщения, например:

trait ScalaActorRef { this: ActorRef =>
  ...

  def !(message: Any)(implicit sender: ActorRef = null): Unit

  ...
}

на sender подразумевается. В актере есть определение, которое выглядит так:

trait Actor {
  ...

  implicit val self = context.self

  ...
}

это создает неявное значение в пределах вашего собственного кода, и оно позволяет делать простые вещи, как это:

someOtherActor ! SomeMessage

теперь вы можете сделать это, если хотите:

someOtherActor.!(SomeMessage)(self)

или

someOtherActor.!(SomeMessage)(null)

или

someOtherActor.!(SomeMessage)(anotherActorAltogether)

но обычно вы этого не делаете. Вы просто сохраняете естественное использование, которое стало возможным благодаря неявному определению значения в черте актера. Есть миллион других примеров. Классы коллекции огромны. Попробуйте побродить по любой нетривиальной библиотеке Scala, и вы найдете грузовместимость.

один пример операции сравнения Traversable[A]. Е. Г. max или sort:

def max[B >: A](implicit cmp: Ordering[B]) : A

они могут быть разумно определены только тогда, когда есть операция < on A. Так, без неявные преобразования, мы должны поставить контекст Ordering[B] каждый раз, когда мы хотели бы использовать эту функцию. (Или отказаться от статической проверки типа внутри max и риск ошибки во время выполнения броска.)

Если, однако, неявное сравнение класс в объеме, например некоторые Ordering[Int], мы можем просто использовать его сразу или просто изменить метод сравнения, указав другое значение для неявного параметра.

конечно, имплициты могут быть затемнены, и, таким образом, могут быть ситуации, в которых фактическое имплицитное, которое находится в области действия, недостаточно ясно. Для простого использования max или sort это действительно может быть достаточно, чтобы иметь фиксированный заказ trait on Int и используйте некоторый синтаксис, чтобы проверить, доступна ли эта черта. Но это будет означать что не может быть дополнительных признаков, и каждый фрагмент кода должен будет использовать признаки, которые были первоначально определены.

дополнение:
ответ глобальная переменная сравнение.

я думаю, вы правы, что в коде обрезается как

implicit val num = 2
implicit val item = "Orange"
def shopping(implicit num: Int, item: String) = {
  "I’m buying "+num+" "+item+(if(num==1) "." else "s.")
}

scala> shopping
res: java.lang.String = I’m buying 2 Oranges.

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

кроме того, это означает, что практически, неявные переменные используются только тогда, когда есть не обязательно уникальный, но внятный экземпляра типа. The self ссылка на актера является хорошим примером для такой вещи. Другим примером является класс type. Могут быть десятки алгебраических сравнений для любого типа, но есть один, который является особенным. (На другом уровне, фактическое номер строки в самом коде также может быть хорошей неявной переменной, если она использует очень отличительный тип.)

вы обычно не используете implicits для повседневных типов. И со специализированными типами (например,Ordering[Int]) существует не слишком большой риск в затенении их.

еще одно хорошее общее использование неявных параметров-сделать тип возврата метода зависящим от типа некоторых переданных ему параметров. Хорошим примером, упомянутым Йенсом, является структура коллекций и такие методы, как map, чья подпись, как правило, является:

def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom[GenSeq[A], B, That]): That

обратите внимание, что возвращаемый тип That определяется наилучшей подгонкой CanBuildFrom что компилятор может найти.

для другого примера этого см. что ответ. Там, возвращаемый тип метода Arithmetic.apply определяется в соответствии с определенным неявным типом параметра (BiConverter).

Это легко, просто запомни:

• чтобы объявить переменную, которая будет передана как неявная тоже
• чтобы объявить все неявные параметры после неявных параметров в отдельном ()

например

def myFunction(): Int = {
  implicit val y: Int = 33
  implicit val z: Double = 3.3

  functionWithImplicit("foo") // calls functionWithImplicit("foo")(y, z)
}

def functionWithImplicit(foo: String)(implicit x: Int, d: Double) = // blar blar

основываясь на моем опыте, нет реального хорошего примера для использования параметров implicits или преобразования implicits.

небольшое преимущество, используя неявные преобразования (не нужно явно написать параметр или тип) является избыточным по сравнению с проблемами, которые они создают.

Я разработчик в течение 15 лет и работаю с scala в течение последних 1,5 лет.

Я видел много раз ошибки, которые были вызваны разработчиком, не зная о том, что использовать неявные преобразования, и что конкретная функция на самом деле возвращает другой тип, тот, что указан. Из-за неявного преобразования.

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

import org.some.common.library.{TypeA, TypeB}

или:

import org.some.common.library._

оба кода будут компилироваться и запускаться. Но они не всегда будут давать одни и те же результаты, поскольку вторая версия импорта подразумевает преобразование, которое заставит код вести себя по-разному.

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

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

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

дополнительные причины того, почему я вообще против неявные преобразования являются:

• они затрудняют понимание кода (кода меньше, но вы не знаете, что он делает)
• время компиляции. код scala компилирует гораздо медленнее при использовании неявные преобразования несколько.
• на практике он меняет язык со статически типизированного на динамически типизированный. Это правда, что после очень строгих правил кодирования вы можете избежать таких ситуаций, но в реальном мире это не всегда так. Даже использование IDE "удалить неиспользуемые импорт" может привести к компиляции и запуску кода, но не так, как до удаления "неиспользуемых" импорт.

нет возможности скомпилировать scala без implicits (если есть, пожалуйста, исправьте меня), и если бы была опция, ни одна из общих библиотек Scala сообщества не компилировалась бы.

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

Scala имеет много отличных функций, и многие не так велики.

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

неявные параметры активно используются в API коллекции. Многие функции получают неявный CanBuildFrom, который гарантирует, что вы получите "лучшую" реализацию коллекции результатов.

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

я комментирую этот пост немного поздно, но я начал изучать scala в последнее время. Даниэль и другие дали хороший фон о неявном ключевом слове. Я бы предоставил мне два цента на неявную переменную с точки зрения практического использования.

Scala лучше всего подходит для написания кодов Apache Spark. В Spark у нас есть контекст spark и, скорее всего, класс конфигурации, который может извлекать ключи/значения конфигурации из файла конфигурации.

Теперь, Если Я имейте абстрактный класс, и если я объявляю объект конфигурации и контекст искры следующим образом: -

abstract class myImplicitClass {

implicit val config = new myConfigClass()

val conf = new SparkConf().setMaster().setAppName()
implicit val sc = new SparkContext(conf)

def overrideThisMethod(implicit sc: SparkContext, config: Config) : Unit
}

class MyClass extends myImplicitClass {

override def overrideThisMethod(implicit sc: SparkContext, config: Config){

/*I can provide here n number of methods where I can pass the sc and config 
objects, what are implicit*/
def firstFn(firstParam: Int) (implicit sc: SparkContext, config: Config){ 
    /*I can use "sc" and "config" as I wish: making rdd or getting data from cassandra, for e.g.*/
    val myRdd = sc.parallelize(List("abc","123"))
}
def secondFn(firstParam: Int) (implicit sc: SparkContext, config: Config){
 /*following are the ways we can use "sc" and "config" */

        val keyspace = config.getString("keyspace")
        val tableName = config.getString("table")
        val hostName = config.getString("host")
        val userName = config.getString("username")
        val pswd = config.getString("password")

    implicit val cassandraConnectorObj = CassandraConnector(....)
    val cassandraRdd = sc.cassandraTable(keyspace, tableName)
}

}
}

Как мы можем видеть код выше, у меня есть два неявных объекта в моем абстрактном классе, и я передал эти две неявные переменные как неявные параметры функции/метода/определения. Я думаю, что это лучший вариант использования, который можно изобразить с точки зрения использования неявных переменных.