Scala

[metaclass]

Читаю книжку Одерского, до основной шизы еще не добрался, но такое ощущение, что в скале чрезмерно много синтаксического сахара. Типа "тут вы можете скобки опустить, а тут вместо скобок использовать фигурные скобки, а тут мы прямо в параметрах класса сделаем их полями, а в multiline string literal вы можете сделать отступ и stripMargin" и прочая и прочая в том же духе.
Основное из этого, видимо - function literals и вызов методов в стиле a methodName b, без точек и скобок, что делает код более лаконичным, одновременно позволяя при желании превратить код в нечитабельный ад.

Заодно по наводке jdevelop глянул на http://spray.io/ https://github.com/spray/spray/wiki
Примеры там, конечно, знатный abuse возможностей языка и вычислений на типах, типа extraction-директив с HList в качестве параметра типа.

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

PS: Вот, к примеру:
https://github.com/spray/spray/blob/master/docs/documentation/spray-routing/code/docs/HttpServiceExamplesSpec.scala

В SimpleService HttpResponse реализован как html-код написанный прямо внутри скала-кода. Сижу уже 30 минут ищу, где это преобразование реализовано и как. Т.е. не видя отдельных литералов и их типов (которые без загрузки всего оного кода с зависимостями в IDE/интерпретатор еще и не увидишь), с ходу догадаться, что происходит, достаточно сложно. XML literals, встроенные в язык и где-то implicit для конверсии.

PPS: implicit evidence:
http://jim-mcbeath.blogspot.com/2008/11/scala-type-infix-operators.html
http://stackoverflow.com/questions/3427345/what-do-and-mean-in-scala-2-8-and-where-are-they-documented

По-моему, это уже достаточно сложно, чтобы увлечь психов и стать новыми крестиками. Вот xeno_by еще приделает макросы - и совсем хорошо станет.

Comments

[xeno-by.livejournal.com]

Специальный синтаксис, да. Можно написать ident => T1 with T2 ... with TN. Это будет означать, что трейт разрешено наследовать только тем, кто имплементит все Ti.

[sum-erman.livejournal.com]

Как всё сложно. Зачем так жить? :) Я там выше ещё спрашивал про зоопарк из object/class/trait и методов их композиции, есть чего почитать по сабжу просветляющего?

[xeno-by.livejournal.com]

Все это просто надо рассматривать в контексте кейк-паттерна, который включает в себя трейты, селф-тайпы и абстрактные тайп мемберы.

Описан паттерн в папере Scalable Component Abstractions. Вот тут еще есть пример, только мне сложно сказать как оно в качестве введения: https://www.precog.com/blog-precog-2/entry/existential-types-ftw.

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

[sum-erman.livejournal.com]

Т.е. фактически в языке есть фича нужная чисто для имплементации "этого вашего" паттерна-который-торт, при том, что каррированные ф-ии + частичное применение сами по себе неплохо справляются с этой задачей. Я видимо недостаточно Enterprise парень чтобы понять всю сложность и необходимость всех этих вывертов с dependency injection

[xeno-by.livejournal.com]

Dependency injection здесь сбоку припеку.

Кейк-паттерн это воплощение способа модуляризации программ, реализованного в Скале (см. паперу, которую я посоветовал выше). Модуляризация, на мой взгляд, полезна не только в энтерпрайзе.

[xeno-by.livejournal.com]

Я не очень понимаю как взять два отдельных компонента и смешать их вместе при помощи частичного применения.

[sum-erman.livejournal.com]

Я честно хотел написать нормальный пример, но мне лень. Попытаюсь кратко обрисовать на словах.

Если мы хотим некоторый компонент параметризовать некоторыми поведениями/структурами данных то достаточно соорудить его в виде функции(ий) от ф-ий реализующих поведения, ф-ий аксессоров и, собственно, своего "смыслового" параметра. Так вот, ежели применить данную функцию ко всему кроме "смыслового" параметра как раз получится сущность соответствующая классу, полностью конкретизированному и обвешанному trait'ами. (Очевидно всё это можно проделать не только с одной ф-й, а с но и с "интерфейсом" целиком)

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

P.S.: окончательного мнения "нужно ли вообще тащить объекты?" я ещё не выработал.

[isorecursive.livejournal.com]

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

[xeno-by.livejournal.com]

Про зоопарк.

trait = строительный материал, атомарная единица композиции. Сами по себе они инстациируются редко, хоть и есть соответствующая конструкция в языке.

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

object = модуль. Как package, только first-class сущность, т.е. модули можно передавать в методы и возвращать из методов. Частый сценарий использования - напихать в object чего-нибудь (например, замиксить кучу трейтов) и потом сделать import someObj._, чтобы импортировать все напиханное.

[sum-erman.livejournal.com]

Это если с ОО стороны смотреть. С функциональной чего я только не видел — коллекции (например) делают и из class'ов и из trait'ов. "Единичные" значения делают и как val и как object. Голова кругом %)