Здравствуйте, VladD2, Вы писали:
VD>Ну, почему же? Есть! Не поддерживать .NET, что они в общем-то и делают.
Производительность скаловских дженериков от этого лучше не становится. Да и вообще — Скала не промышленный язык даже близко, это скорее полномасштабный эксперимент. Будет ли кто то на базе Скалы делать мейнстримовый компилятор — большой вопрос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD>Просто наличие некой вещи имеет значение только при некоторых условиях. Например, мне пофигу на то что есть Бугати Веерон просто потому, что я не могу им воспользоваться. Та же фигня и со скалой. Невозможность воспользоваться дотнет-дженериками и низкая производительность делает для меня этот язык неприменимым.
Ну тут я не согласен.
Во-первых, чем больше ФЯ под CLR, тем лучше. У людей будет формироваться интерес к ФЯ как таковым. К тому же Скала язык все же достаточно известный.
Во-вторых, не вижу, почему Scala@CLR должна быть медленее, чем Scala@JVM
Ну и наконец, как я понимаю, производительность будет проседать все же во вполне конкретных сценариях, и не всегда это будет заметно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну и наконец, как я понимаю, производительность будет проседать все же во вполне конкретных сценариях, и не всегда это будет заметно.
Проблема только в том, что сценариев с использованием дженериков становится все больше. По сути, их массово нет только в UI, но там и функциональщина не особо нужна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Ну и наконец, как я понимаю, производительность будет проседать все же во вполне конкретных сценариях, и не всегда это будет заметно. AVK>Проблема только в том, что сценариев с использованием дженериков становится все больше. По сути, их массово нет только в UI, но там и функциональщина не особо нужна.
Проблема с "ненастоящими" генериками, как я понимаю, прежде всего в упаковке. Там где упаковка не требуется, т.е. для референс-типов, и CLR не генерит отдельные типы. Т.е. даже генерики будут медленнее далеко не всегда, а лишь в ряде конкретных случаев.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Проблема с "ненастоящими" генериками, как я понимаю, прежде всего в упаковке.
Не только. Постоянный кастинг в полиморфных коллекциях тоже не бесплатен, особенно для интерфейсов.
ВВ> Там где упаковка не требуется, т.е. для референс-типов, и CLR не генерит отдельные типы.
Но устраняет кастинг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, FR, Вы писали:
AVK>>Вопрос в том, какую. Люк в свое время говорил, что текущее видение на F# — экспериментальный язык для гиков.
FR>Так не пойдет это место уже давно Хаскелем занято.
Пойдет. Хаскель далеко не идеален. И для дотнета он код генерить не умеет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Проблема с "ненастоящими" генериками, как я понимаю, прежде всего в упаковке. AVK>Не только. Постоянный кастинг в полиморфных коллекциях тоже не бесплатен, особенно для интерфейсов.
А в JVM кастинг есть?
ВВ>> Там где упаковка не требуется, т.е. для референс-типов, и CLR не генерит отдельные типы. AVK>Но устраняет кастинг.
А тут можно по-подробнее? Каким образом устраняется кастинг?
Здравствуйте, Воронков Василий, Вы писали:
AVK>>Не только. Постоянный кастинг в полиморфных коллекциях тоже не бесплатен, особенно для интерфейсов.
ВВ>А в JVM кастинг есть?
Скорее всего.
AVK>>Но устраняет кастинг.
ВВ>А тут можно по-подробнее? Каким образом устраняется кастинг?
В CLR есть гарантия, что несовместимые типы в дженерик не придут. Следовательно, джиту нет необходимости делать проверки. А вот в случае джавовских дженериков туда приходит object и при вызове специфичного метода нужно сделать проверку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
FR>>Так не пойдет это место уже давно Хаскелем занято.
AVK>Пойдет. Хаскель далеко не идеален. И для дотнета он код генерить не умеет.
Для гиков F# слабоват, вообще это надо умудрится взять самый практичный функциональный язык (OCaml) и
пытаться из него делать язык для гиков.
Здравствуйте, FR, Вы писали:
AVK>>Пойдет. Хаскель далеко не идеален. И для дотнета он код генерить не умеет.
FR>Для гиков F# слабоват, вообще это надо умудрится взять самый практичный функциональный язык (OCaml) и FR>пытаться из него делать язык для гиков.
Да, мужики! Вам бы только по спорить, а о чем уже не важно.
Неужели тебе не ясно что имели в виду те люди из МС которые сказали фразу про гиков?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
N>>Главным образом, их туда вводили для интероперабельности с джавовскими wildcards (которые тоже являются урезанной разновидностью экзистенциальных типов). Ну и, вообще, это сильный инструмент для абстракции.
VD>Для абстракции в ООЯ нужно применять ООП. Мне кажется, что они уходят не в ту степь. Вместо простого и удобного языка для массового рынка они уходят в нишу "крутых" (читать как переусложненных) языков а-ля Хаскель.
Я напарываюсь постоянно, когда в фреймворке надо работать с коллекциями объектов, по разному параметризованных. Грубо говоря:
// framework:
class FormField[AppData]
class Form {
lazy val fieldsByName: Map[String, FormField[_]] = { /* получаем через рефлексию */ }
}
// app:
class MyForm extends Form {
val email = new FormField[String] (...)
val age = new FormField[Int] (...)
}
Здравствуйте, dimgel, Вы писали:
D>Я напарываюсь постоянно, когда в фреймворке надо работать с коллекциями объектов, по разному параметризованных. Грубо говоря:
D>
D>// framework:
D>class FormField[AppData]
D>class Form {
D> lazy val fieldsByName: Map[String, FormField[_]] = { /* получаем через рефлексию */ }
D>}
D>// app:
D>class MyForm extends Form {
D> val email = new FormField[String] (...)
D> val age = new FormField[Int] (...)
D>}
D>
D>Как это сделать без wildcards?
Опиши исходную задачу. То что я вижу из приведенного кода — это какая-то попытка реализовать динамику в статически типизированном языке. Есть огромная вероятность того, что сама необходимость вызвана некоторыми ограничениями в зыке, или попросту неверным дизайнерским выбором.
Сам факт использования рефлексии зачастую является признаком проблем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Опиши исходную задачу. То что я вижу из приведенного кода — это какая-то попытка реализовать динамику в статически типизированном языке. Есть огромная вероятность того, что сама необходимость вызвана некоторыми ограничениями в зыке, или попросту неверным дизайнерским выбором.
Дык задача была простая: удобный модуль форм, без необходимости пользователю фреймворка писать кучу boilerplate-кода. В частности, значения атрибута name для <input/> берутся через рефлексию из имён полей класса. Т.е. в шаблоне формы юзер пишет
где значение поля берётся из одноимённого поля переданного в форму DTO (вот эту работу с состоянием я возможно сделаю явной, добавляя геттеры/сеттеры в объявление поля, хотя букв в пользовательском коде сразу станет намного больше).
VD>Сам факт использования рефлексии зачастую является признаком проблем.
Во всех известных мне java-фреймворках рефлексия используется чуть более, чем всегда.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, VladD2, Вы писали:
VD>>Опиши исходную задачу. То что я вижу из приведенного кода — это какая-то попытка реализовать динамику в статически типизированном языке. Есть огромная вероятность того, что сама необходимость вызвана некоторыми ограничениями в зыке, или попросту неверным дизайнерским выбором.
D>Дык задача была простая: удобный модуль форм, без необходимости пользователю фреймворка писать кучу boilerplate-кода. В частности, значения атрибута name для <input/> берутся через рефлексию из имён полей класса. Т.е. в шаблоне формы юзер пишет D>
где значение поля берётся из одноимённого поля переданного в форму DTO (вот эту работу с состоянием я возможно сделаю явной, добавляя геттеры/сеттеры в объявление поля, хотя букв в пользовательском коде сразу станет намного больше).
Для ASP.NET MVC можно писать так:
<td>@Html.EditorFor(m => m.Email)</td>
Выделенное — код на C#, который будет проверяться при компиляции.
Там конечно внутри будет рефлексия работать.
Уверен что на nemelre можно не хуже шаблонизатор сделать, который еще на валидность разметку проверять будет.
VD>>Сам факт использования рефлексии зачастую является признаком проблем. D>Во всех известных мне java-фреймворках рефлексия используется чуть более, чем всегда.
Потому что java — очень слабый язык.
Здесь m — это что?
G>Там конечно внутри будет рефлексия работать.
Во-во, при реализации фреймворка без рефлексии никуда.
D>>Во всех известных мне java-фреймворках рефлексия используется чуть более, чем всегда. G>Потому что java — очень слабый язык.
Да у Немерле у самого название ещё то 
Если нам не помогут, то мы тоже никого не пощадим.
