?

Log in

No account? Create an account

Зачем нужны имплисит макросы? - Excelsior — LiveJournal

May. 7th, 2013

11:06 pm - Зачем нужны имплисит макросы?

Previous Entry Share Next Entry

Comments:

From:zhengxi
Date:May 7th, 2013 11:28 pm (UTC)
(Link)
Такая еретическая мысль:

Вот есть у вас в папере пример:
val unpickld = pickl.unpickle[Any] match {
  case Firefighter(name, since) => ...
  case x: Int => ...
...
}

Пример, возможно, далёк от практики, но сейчас важно будут только то, что параметр unpickle (тут Any) - это не-sealed class, а это уже не так далеко.
Получается, что тут будет задействован runtime unpickler, так?
Даже если ничего другого (кроме Firefighter и Int) тут не придётся распаковывать, это будет делаться через runtime reflection.

Дальше.
Эта ваша библиотека - хорошая попытка окончательного решения вопроса сериализации, и runtime unpicker, как последний островок тормознутости, рано или поздно будет заменён (неважно вами или форкерами) на динамическую генерацию JVM-байткода (или даже на компиляцию на лету Scala-кода), с периодической перегенерацией, если вдруг стал часто прилетать новый тип данных.

И встанет вопрос - а зачем тогда макросы? 3ачем вообще Scala?
Ведь эта часть будет работать так же быстро, как и код, сгенерённый макросами (ok, не сразу, после некоторого "прогрева"), и её можно сделать на старой доброй Java.
И почему такого до сих пор нет?
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 8th, 2013 06:55 am (UTC)
(Link)
Да, с не-sealed классами есть проблема в том плане, что хотелось бы во время компиляции искать всех их наследников, но для этого нет простого способа, поэтому приходится или как-то выкручиваться (что пока что получается не очень), или тормозить.

Для данного конкретного случая можно наколбасить клевый макрос, который полностью решит проблему, проэнумерировав возможные случае в компайл-тайме:
val unpickld = pickl.unpickle {
  case Firefighter(name, since) => ...
  case x: Int => ...
...
}
В принципе, там уже есть компиляция Скалы на лету. Генерится точно такой же код, что был бы сгенерирован в компайл-тайме, если был бы известен тип, а потом он компилируется тулбоксом. Пока что результаты компиляции не кэшируются, т.к. не успели, но это планируется.

Рантайм аналог так же быстро работать не будет, т.к. он не будет знать все типы, часть из которых сотрется во время erasure. Поэтому, как я понимаю, мы уделываем Kryo на сериализации коллекций (я сам в бенчмаркинге участия не принимал, поэтому насчет деталей не в курсе и говорю только свои гипотезы) - при всем желании вместо Vector[Int] Kryo видит Vector, поэтому он не сможет сгенерировать специализированный код. Предположим, в случае коллекций можно выкрутиться при помощи toArray, но, наверняка, возможны случаи, когда не выкрутишься.

Edited at 2013-05-08 06:56 am (UTC)
(Reply) (Parent) (Thread)
From:zhengxi
Date:May 9th, 2013 02:02 pm (UTC)
(Link)
да, ты прав.
хороший повод перейти на 2.10.2 :)
(Reply) (Parent) (Thread)