Комментарии 21
Немного не в тему, но. Подобную KAnnotator тулзу, но для .NET планируете выпустить?
ReSharper что-то такое умеет. Выпускать отдельно пока не планировали
На свой страх и риск запускаете VS с ключиком /ReSharper.Internal, аннотатор находится в ReSharper | Internal | Annotator, умеет рендерить выведенные из кода аннотации в XMLники или в атрибуты в коде.
Никаких гарантий :)
Никаких гарантий :)
Круто! Поздравляю с M4! Когда у вас финальный-то релиз?
И ещё вопрос — Вы c коллегами планируете использовать Kotlin при разработке IDEA 13?
И ещё вопрос — Вы c коллегами планируете использовать Kotlin при разработке IDEA 13?
По-моему, что Kotlin, что Ceylon, с каждым релизом все больше становятся похожи на Scala с разницей только в синтаксисе и с опозданием года на 3-4.
:)
Ну, серьезно, вы можете назвать хоть одну неполитическую причину использовать Kotlin или Ceylon вместо Scala?
Есть вот этот замечательный документ, но он, понятно, несколько biased, несколько устарел и, самое главное, каких-то радикальных различий не называет.
Option'ы в Scala и "?" в Kotlin — по сути — одно и то же, с некими плюсами и минусами и с одной, и с другой стороны. Implicit'ы и extension functions — по сути тоже одно и то же — в Scala, кстати, с 2.9 где-то к такой модели явного их вызова тоже постепенно приходят там, где это необходимо.
Modules — де факто польза от них ровно так же, что от аналогичного механизма в SBT или в Maven. Smart casts — это такой pattern matching, просто записанный иначе (и, субъективно, форма из Kotlin не самая удобная)…
Есть вот этот замечательный документ, но он, понятно, несколько biased, несколько устарел и, самое главное, каких-то радикальных различий не называет.
Option'ы в Scala и "?" в Kotlin — по сути — одно и то же, с некими плюсами и минусами и с одной, и с другой стороны. Implicit'ы и extension functions — по сути тоже одно и то же — в Scala, кстати, с 2.9 где-то к такой модели явного их вызова тоже постепенно приходят там, где это необходимо.
Modules — де факто польза от них ровно так же, что от аналогичного механизма в SBT или в Maven. Smart casts — это такой pattern matching, просто записанный иначе (и, субъективно, форма из Kotlin не самая удобная)…
Что за зверь этот Ceylon.
Слон: ceylon-lang.org
А когда планируется плагин для эклипса? Его очень не хватает, чтобы начать подсаживать коллег.
А вы не думали улучшить reflection в Котлине? Чтобы была возможность получать объекты Field, Method и т.д. не только через поиск по строковому имени, а более статически типизировано.
Например, что-нибудь типа этого:
Такая возможность позволит избавиться от кодогенерации в очень большом количестве случаев (типичные примеры похожего подхода, но с кодогенерацией — Querydsl, Criteria Query и т.д.)
Например, что-нибудь типа этого:
public class MyClass() {
public var myField String = ...
fun myFun() : Unit { ... }
fun myFun(s : String) : String { ... }
}
// Над generic-ами особо не думал, возможно такой вариант не оптимален. В примере я использовал типизацию по двум классам, где первый - это класс, откуда берётся поле или метод, а второй - тип поля или возвращаемого значения метода.
Field<MyClass, String> cityField = MyClass.#myField // "#" используется для указания того, что берётся не значение поля, а само поле класса как объект
Method<MyClass, Unit> myFun1Method = MyClass.#myFun() // скобки показывают, что нас интересует метод, а не поле
Method<MyClass, String> myFun2Method = MyClass.#myFun(String.class) // указывая типы параметров определяем, какой именно метод из перегруженных нас интересует
Такая возможность позволит избавиться от кодогенерации в очень большом количестве случаев (типичные примеры похожего подхода, но с кодогенерацией — Querydsl, Criteria Query и т.д.)
Думали, сделаем: youtrack.jetbrains.com/issue/KT-1183
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел Kotlin M4