Я, как член команды DefinitelyTyped (типизации TypeScript для разных JS библиотек), могу сказать, что часто.
Часто приходится описывать множеством перегрузок (конечным), то, что проще описать вариативным шаблоном.
Есть библиотеки, котороые из одной (или больше) функции превращают в другую, попутно меняя входные/выходные данные по определенным правилам (оборачивают во что-то, добавляют/удаляют параметры).
Тут проблама с ковариантностью/контравариантностью.
Т.к. TypeScript имеет структурную типизацию, то считается, что он выводит ковариантность при операциях.
Но вот, в случаях функциях, нужно знать вариантность на уровне сигнатуры.
function push<T>(data: T[], a: T): void {
data.push(a); // здесь в data заносятся данные, т.е. подойдут типы >=T, т.е. T - контравариантен
}
Значит, при вызове push([1], "string") — общий тип не может быть найден.
Но вот, при вызове push(animals, dog) — тип T должен быть выведен как Animal.
Т.е. надо бы либо указывать явно (как минимум в случае declare инструкций) вариантность типа, либо выводить автоматически по реализации (только чтение — ковариантен, только запись — контравариантен).
Насколько я помню, есть какой-то способ создать контракты для библиотек.
Т.е. создать «внешнее» описание контракта библиотеки. Так поступет сам CodeContracts, предоставляя контракты для классов .Net.
Если на клиенте, то RxJS отлично подходит для многих задач. Особенно в связке с MVVM фреймворками.
На сервере можно применять обычно нет нужды. Отлично подходит, когда есть много асинхронных потоков данных.
Сайт, видимо, давно не обновляли. Видюшка старая лежит. Но проект очень даже развивается. Его основные контрибуторы — это Paul Betts и Phil Haack. Эти чуваки работали в MS, а сейчас работают в GitHub. На RxUI в частности сделан GitHub for Windows.
Самый крутой MVVM — это RxUI (ReactiveUI). GitHub, сайт. Очень рекомендую, особенно для тех, кто уважает Rx. Работает под XAML, Silverlight, WP8, WinRT, iOS, Android (Xamarin).
Есть такой проект — knockout-projections, от автора Knockout (запись в блоге). В нем есть примерно то, что сделали вы. Не все, конечно. Но у него принцип работы другой — он не создает в памяти новые массивы, а проецирует лениво.
Парсеры отлично писать на Rxx (Extensions for Reactive extensions). Там внизу есть много ссылок о том как описывать парсеры с помощью монад (в синтаксисе LINQ).
Привет Булат, Боря. Мы с вами на сабантуе были. Я вам помогал немного с проектом =)
Удачи!
С Google API не перешли ни на что другое? Он все-таки коряво распознает.
Как раз-таки, насколько помню, async/await — это языковая фича C# и не нуждается в .Net 4.5. Просто нужна еще runtime-поддержка на уровне библиотеки (TaskBuilder, кажется). Есть даже NuGet пакет Microsoft.Bcl.Async, который позволяет использовать эту фичу на .Net 4.0.
И вообще, 4.5 работает на CLR 4.0.
Отправил в этом сервисе информацию об SMS, которое получил единственный раз пару недель назад.
Через пару минут после отправки, получил в точности такое SMS еще раз! Это меня троллит сервис или оператор?
У команды Rx есть Ix (Interactive extensions), доступный в NuGet. Там есть EnumerableEx, который всё то, что есть в Rx для IQueryable повторяет для IEnumerable. Ну так вот там списочек расширений подлиннее немного.
А morelinq посмотрим, спасибо.
Я разработчик Sass.Net и проект менеджер Web Essentials недавно ко мне обращался по поводу того, что хотят встроить поддержку sass/scss на новом уровне.
Так что над этим работают, знаю точно =)
Часто приходится описывать множеством перегрузок (конечным), то, что проще описать вариативным шаблоном.
Есть библиотеки, котороые из одной (или больше) функции превращают в другую, попутно меняя входные/выходные данные по определенным правилам (оборачивают во что-то, добавляют/удаляют параметры).
Т.к. TypeScript имеет структурную типизацию, то считается, что он выводит ковариантность при операциях.
Но вот, в случаях функциях, нужно знать вариантность на уровне сигнатуры.
Значит, при вызове
push([1], "string")— общий тип не может быть найден.Но вот, при вызове
push(animals, dog)— тип T должен быть выведен как Animal.Т.е. надо бы либо указывать явно (как минимум в случае declare инструкций) вариантность типа, либо выводить автоматически по реализации (только чтение — ковариантен, только запись — контравариантен).
Пожалуй, зафайлю это соображение к ним на GitHub.
Т.е. создать «внешнее» описание контракта библиотеки. Так поступет сам CodeContracts, предоставляя контракты для классов .Net.
На сервере можно применять обычно нет нужды. Отлично подходит, когда есть много асинхронных потоков данных.
Удачи!
С Google API не перешли ни на что другое? Он все-таки коряво распознает.
И вообще, 4.5 работает на CLR 4.0.
Если это .Net, то будет работать в Windows Phone 7/8, в Mono для Android и iOS (Xamarin)?
Через пару минут после отправки, получил в точности такое SMS еще раз! Это меня троллит сервис или оператор?
А morelinq посмотрим, спасибо.
Так что над этим работают, знаю точно =)