2016-04-03 3 views
2

Изучая Scala, я нашел понятие неявным трудно рационализировать. Это позволяет передавать значения неявно, без явного упоминания их.Какова основная техническая проблема, которую неявно решает Скала?

Какова его цель для бытия и в чем проблема, которую она пытается решить?

+0

Им нужно было получить http://scalapuzzlers.com/ с земли. –

+0

Святое Я не понимал, сколько головоломок есть у Скалы. – Ana

+0

Этот вопрос допускает много плохих ответов, но также хороших и лаконичных. –

ответ

-1

Его глубокий вопрос действительно Это очень мощный инструмент, и вы можете использовать их для написания абстрактного кода, например, типов и т. Д. Я могу порекомендовать некоторые обучающие программы, которые вы можете изучить, а затем мы можем поговорить, может быть, когда-нибудь :) Это все о предоставлении разумных по умолчанию в вашем коде. Также магия вызывает, по-видимому, не существующие методы на объектах, которые просто работают! Все эти хорошие вещи делаются через имплициты. Но при всей его силе это может заставить людей написать действительно плохой код. Пожалуйста, смотрите здесь презентацию Ника Партриджа, и я уверен, что если вы код вместе с ним, вы поймете, почему и как приближаться к имплицитам. Watch it here

Dick Walls excellent presentation with live coding Часы обеих частей.

+0

Почему отрицательный голос? да в любом случае. –

+0

Угадайте, что нисходящий сигнал объясняется тем, что ответы не должны ссылаться на ресурсы за пределами, чтобы дать ответ. Ответ должен быть обобщен. Кроме того, ваш ответ не поддерживает то, что подразумевается в отношении «разумных дефолтов» как «основной технической проблемы». Не используются ли аргументы по умолчанию для разумных значений по умолчанию? –

+0

hmm gotcha. Затем обновит больше информации. :) THX для ответа. –

1

Существует paper about type classes с older slides и discussion.

Способность неявно передавать объект, который кодирует класс типа, упрощает шаблон.

Одерски просто ответил на critique of implicits что

Scala не будет Scala, если она не имеет неявные параметры и классы.

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

+0

Еще одна замечательная особенность этой статьи - сноска, показывающая, какая ветка хранилища Adriaan Moors проверяется, чтобы примеры были скомпилированы под '-Xexperimental'. –

+0

Я знаю классы классов и Haskell хорошо, но я не вижу связи между неявными и типами классов. – Ana

+0

@Ana: тогда вы должны прочитать статью «[Классы классов как объекты и имплициты] (https://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf)», что в значительной степени объясняет это. Суть в том, что вы знаете, как GHC передает скрытые словари методов в своей реализации классов типов? Ну, «проходящая вокруг» часть достигается с помощью implicits, а что такое «словарь методов», отличный от объекта? –

3

В его сердце implicit является способом расширения поведения значений типа таким образом, который полностью контролируется на локальном уровне в вашей программе и является внешним по отношению к исходному коду, который определяет эти значения. Это один из способов решения проблемы expression problem.

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

Например, вместо классов моделей данных, содержащих поведение сериализации JSON, вы можете сохранить это поведение в другом месте и неявно увеличить объект с возможностью сериализации. Это сводится к определению в экземпляре implicit, в котором указано, как ваш объект можно рассматривать как «сериализуемый JSON», а не его оригинальный тип, и он выполняется без редактирования реального типа объекта.

Существует несколько форм implicit, которые являются pretty thoroughly covered elsewhere. Варианты использования включают в себя расширение шаблона my-library, шаблон typeclass, неявные преобразования и инъекции зависимостей.

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

Enhance-моя библиотека и классы типов

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

В Haskell модельные категории существуют как первоклассная концепция. Тем не менее, они глобальны, так что вы не получаете локальный контроль над тем, какой тип класса применяется в данной ситуации. В Scala вы контролируете, какие импликации находятся в области локально, через импортируемые модули. И вы всегда можете полностью отказаться от неявного разрешения, явно передавая параметры.

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

Неявных преобразований

Много других языков не имеют возможностей для достижения этой цели. Но в Скале это стало нахмуриться, так что, возможно, это справедливо.

Смежные вопросы