Здравствуйте, D. Mon, Вы писали:
DM>Кроме того, мне эта задача интересна не в сравнении с C#, а в сравнении с другими современными языками.
Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, vdimas, Вы писали: V>>Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так? K>Для Complex работает, для int, float, double пишете имплементации CReal и тоже работать будет.
Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.
V>>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int. K>В чем демогогия? Какая проблема со "встроенным" int?
Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад. Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика, например, встроенные типы поддерживают IConvertible, поэтому можно довольно быстро отсечь семейство нужных типов. Для остальных можно попытаться через рефлексию найти переопределенные операторы.
V>>Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы. K>Наоборот, решаемо и обычно именно так как я показал и решается, в GHC-хаскеле, например.
В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера. Более того, тип класса-хелпера надо затем всегда указывать явно. В твоём Хаскеле ничего этого делать не надо, как и в С++ — всё подхватывается "само".
V>>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже.
K>Как что-то хорошее.
??
V>>Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
K>В ленивом языке foldr == итератор, все возможности покрываются. В строгом это не так.
Какая из возможностей не покрывается?
K>Вы давайте, не увиливайте, а решайте задачу D.Mon — я вашу решил.
1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
По ссылке объявление типа-контейнера, на котором исходная задача решаема в обобщенном виде и будет работать изкаробки, в отличие от твоего решения.
Опущенную часть решения оставляю для самостоятельной работы, там несложно. ))
Здравствуйте, D. Mon, Вы писали:
DM>>>Я код просил, а не руками махание. Пока ни строчки не получил. V>>Ты пока попросил решение, такое же как где-то. Известная демагогия. Давай задачу целиком.
DM>Не просил я "такое же как где-то", очнись. Задача уже сформулирована.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, vdimas, Вы писали:
V>>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int. V>>Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы.
DM>Ты сам развел демагогию. Вопрос был простейший, с интами. Приплетать комплексные числа и обобщать обобщуемое никто не просил.
Я просил. Тебя. А твой коллега показал, что твой пример — фикция, достаточно было сменить условие с поиска минимального на поиск среднего. И тут ты сел в разгона в лужу. ))) А на Swift решаемы в общем виде оба примера, в отличие от C#.
DM>Кроме того, мне эта задача интересна не в сравнении с C#,
Некрасиво так юлить. )))
Твои же слова были о "сравнении с C# десятилетней давности". Столько пафоса и так громко в лужу.
Че ты такой нервный вообще с этим Swift? Расслабься уже. Не хочешь писать на нём — не пиши. Не понимаешь описания языка — не читай. Не умеешь решать свою же задачу БЕЗ итераторов — не решай... используй только те языки, на которых сможешь решить... какие проблемы?
DM>а в сравнении с другими современными языками. Если попросить Клапауция решить ее на хаскеле, он тоже скажет "на генериках сие нерешаемо"? Смешно же.
На Хаскеле как раз решаемо даже более сложное условие (с арифметическими вычислениями которое). Причем, решаемо и работает изкаробки, в отличие от порнографии на C#.
V>>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
DM>Да все мы поняли. Только того метода у свифтовых коллекций нет(?), поэтому это не решение, а словоблудие.
В твоём условии речь была о именно о пользовательской коллекции. Ты по ссылке ходил или как? Не надоело в лужу падать-то?
Здравствуйте, vdimas, Вы писали:
V>Очнись сам. Я словесное решение ответил сразу же. Твои проблемы, что ты не понимаешь простых вещей. V>Вот тут код: http://www.rsdn.ru/forum/philosophy/5637904.1
Здравствуйте, Klapaucius, Вы писали:
I>>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
K>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
Представь себе, ты продавил банан на Химмельсдорфе и остаётся захватить базу. Противник пытается контратаковать на железной дороге. Ты предлагаешь бросить захват ?
Здравствуйте, vdimas, Вы писали:
I>>Ты не забы, что речь про контейнеры ?
V>Речь о чьей-то упертости, а не о контейнерах. V>Вы настаиваете на итераторах GoF, а я настаиваю на принятом в функциональном виде способа обхода контейнера. С т.з. подхода итераторов — классика IoC. V>Следуя нынешней моде вы в пролете. ))
Ты предлагаешь игнорировать встроеные операторы ? А что еще ты предлагаешь игнорироват в таком классном языке ?
I>>Либу в которой нет внятного дизайна контейнеров, не спасет даже самый лучший язык.
V>Кароч. Мне надоела ваша упертость. Мне прям сейчас некогда ставить виртуалку с новой макосью и разворачивать там среду (на досуге поиграюсь с этим).
Вот как поиграешь, так с кодом и приходи. За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
Здравствуйте, vdimas, Вы написали серию искрометных разоблачений.
V>Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.
Все пропало: ad-hoc полиморфизм не имеет смысла: оказывается, что зависимый от типа код — это просто копипаста и вместо написания всяких имплементаций тайпклассов можно просто копипастить — то на то и получится!
V>Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад.
Все пропало: параметрический полиморфизм не нужен — это разжевали еще 10 лет назад!
V>Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика,
Что, разумеется невозможно при параметрическом полиморфизме, и не совместимо с параметричностью. т.е. либо динамическая безтипизация, либо недозавтипы (хотя-бы GADTы или "язык модулей"), либо шаблонизатор для кода с "текстовой" подстановкой.
Единственный способ "диспетчеризации" по типу при обычном параметрическом полиморфизме в моем примере и продемонстрирован.
V>В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера.
Решение обобщенное, что очевидно следует из типа Avg:
T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
"Явную специализацию класса хелпера" написать конечно надо. Она и в том же хаскеле написана.
V>Более того, тип класса-хелпера надо затем всегда указывать явно.
Это точно, но автоподстановка словарей далеко не везде есть, шарп не один такой инвалид.
V>В твоём Хаскеле ничего этого делать не надо,
Подставлять словари самому не надо, а писать их конечно надо (если они сами не выводятся, но и дотнете можно словари генерировать всякими костыльными способами)
V>как и в С++ — всё подхватывается "само".
В С++ подхватываться нечему, там ни параметрического полиморфизма, ни передачи словаря нет.
K>>Как что-то хорошее. V>??
Как будто то, "что обобщенное программирование в Swift должно быть ближе к C++" — это что-то хорошее.
V>Какая из возможностей не покрывается?
"Продуктивность" свертки, например. Ей нельзя управлять, просто потребляя результат (для чего итератор и нужен). Впрочем, с помощью континьюейшенов можно некий воркараунд накостылить.
V>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает. При этом то, что решение проблемное на тот момент было известно лет 30 и лет 25 как проблемы были решены. Разумеется, этого никто не заметил, пока ручка грабель не ознакомила с ними индустриального разработчика.
Проблема тут не в параметрическом полиморфизме, а в ограничении квантификации с помощью интерфейсов.
Причем в этих пресловутых спорах "10 лет назад" им противостояли сторонники аналогичного костыльного носолюшена, что могло бы быть даже смешным, если бы не было грустным.
Но нормальное решение можно закодировать таким вот костыльным образом. Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках, их разработчики же думают не о том, как обобщенный код писать, а о том, как притянуть за уши какой-нибудь треш-угар вроде "знакомого практикам" наследования или шаблонизирования/подстановки туда, где без них только лучше будет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
Кода-то сколько!
private static T Average<T>(IEnumerable<T> items, Func<T, T, T> add, Func<T, int, T> divide)
{
var count = 0;
var sum = items.Aggregate(default(T), (i, j) => { count++; return add(i, j); });
return divide(sum, count);
}
[Test]
public void Test()
{
var items = new [] { new Complex(1, 2), new Complex(2, 3) };
var average = Average(items, (i, j) => i + j, (v, n) => v / n);
}
HgLab: Mercurial Server and Repository Management for Windows
Н>private static T Average<T>(IEnumerable<T> items, Func<T, T, T> add, Func<T, int, T> divide)
Н>{
Н> var count = 0;
Н> var sum = items.Aggregate(default(T), (i, j) => { count++; return add(i, j); });
Н> return divide(sum, count);
Н>}
Н>[Test]
Н>public void Test()
Н>{
Н> var items = new [] { new Complex(1, 2), new Complex(2, 3) };
Н> var average = Average(items, (i, j) => i + j, (v, n) => v / n);
Н>}
Н>
Самое главное — словарь не используется повторно (по замыслу, это просто часть реализации Complex), а пишется по месту.
Кроме того: замучаетесь всю арифметику по одной функции передавать, да и лямбды не инлайнятся.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Самое главное — словарь не используется повторно (по замыслу, это просто часть реализации Complex), а пишется по месту.
Какой словарь?
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Ikemefula, Вы писали:
I>Вот как поиграешь, так с кодом и приходи.
Использованы только те ср-ва языка, аналоги которых есть в Swift, из описания языка и примеров.
I>За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
Чего-чего? Там были все демонстрации.
Просто ты так и не смог поставить условие задачи. А которое поставил — тебе показали минимум дважды. Тебе не понравилось? — твои проблемы.
Более того, так и не понял принципы работы разных диспетчеров аснхронщины и вообще как она работает. ))
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
A>>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.
I>И запускать эти тесты надо полагать, придется на боевой системе ?
Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".
A>>Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.
I>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
Здравствуйте, vdimas, Вы писали:
I>>За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
V>Чего-чего? Там были все демонстрации.
Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"
Здравствуйте, D. Mon, Вы писали:
DM>Смишно. Распространенный язык, недоступный на линуксе и винде.
Ну т.к. там llvm и есть возможность подключать библиотеки на C, то не вижу никаких проблем для кроссплатформенности, даже если Apple не захочет. Другое дело, что если они не захотят, то скорее всего не будет мощного развития инструментов на других платформах (т.е. будет расклад как у D на всех платформах), а наличие такой поддержки является одним из важных бонусов Swift'a...
DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
Хгм, не ожидал от тебя такого вопроса. Ты же знаешь, что в том же D (да и в C++ и ещё много где) вопросы подобных контейнеров решаются в стандартной библиотеке (описание которой для Swift'a никто из нас тут ещё не видел), а не в конструкциях самого языка. От языка то собственно вообще практически ничего не требуется, максимум какой-то инструмент для поддержки foreach от произвольных коллекций (и такое есть — ты сам показал по ссылке ниже). Так что не вижу вообще никакого смысла обсуждать подобные вопросы, не держа перед глазами описание стандартной библиотеки Swift'a.
P.S. Eсли бы в Swift'е было мощное метапрограммирование (кстати, его ещё не поздно добавить с помощью макросов) и Apple дала бы обещание поддерживать его не только под свои платформы, то на мой вкус такой язык стал бы даже поинтереснее D... Ну а пока что D мне всё же нравится больше. Но это мой специфичный вкус (не боюсь сложного кода, бывающего в МП), а для очень многих Swift может выглядеть идеалом уже даже и такой.
Здравствуйте, andyag, Вы писали:
A>>>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.
I>>И запускать эти тесты надо полагать, придется на боевой системе ?
A>Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".
Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.
I>>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
A>Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию
Например : "А что вернет вон та функция, если перед этим я вызову то и это"
И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
Здравствуйте, Klapaucius, Вы писали:
V>>Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.
K>Все пропало: ad-hoc полиморфизм не имеет смысла: оказывается, что зависимый от типа код — это просто копипаста и вместо написания всяких имплементаций тайпклассов можно просто копипастить — то на то и получится!
Да нет. Оказывается, что ad-hoc полиморфизм не поддерживается в полной мере генериками дотнета, только и всего. Иначе бы он сам подхватывал переопределённые операторы. А тебя просто несет на ровном месте. Знаешь же прекрасно о чем речь, но "баба Яга против" )) Остаётся только язвить. ))
V>>Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад.
K>Все пропало: параметрический полиморфизм не нужен — это разжевали еще 10 лет назад!
Если в полноценной реализации, то нужен, ес-но. Но для привычного ООП он почти всегда "недо-", бо идет только по первому аргументу this.
V>>Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика,
K>Что, разумеется невозможно при параметрическом полиморфизме, и не совместимо с параметричностью. т.е. либо динамическая безтипизация, либо недозавтипы (хотя-бы GADTы или "язык модулей"), либо шаблонизатор для кода с "текстовой" подстановкой.
Ну а что делать, если всё кривое? )))
K>Единственный способ "диспетчеризации" по типу при обычном параметрическом полиморфизме в моем примере и продемонстрирован.
Ты продемонстрировал костыль в условиях "недо-". Но это нахальство какое-то считать всех дураками... бо именно эти костыли обсуждали еще лет 10 назад. Предлагая нарисовать пример на C# я предполагал, что все прекрасно в курсе, о чем речь. Получается, ты один был не в курсе или считаешь всех дураками, "изобретя" сотый вариант одного и того же.
V>>В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера.
K>Решение обобщенное, что очевидно следует из типа Avg: K>
K>T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
K>
Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным.
Можно так:
T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()
Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)
K>"Явную специализацию класса хелпера" написать конечно надо. Она и в том же хаскеле написана.
Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать. Словами я сиё тоже сказал еще несколько постов назад. Не верю, что ты не понял, о чем речь.
Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же! В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))
V>>Более того, тип класса-хелпера надо затем всегда указывать явно. K>Это точно, но автоподстановка словарей далеко не везде есть, шарп не один такой инвалид.
V>>В твоём Хаскеле ничего этого делать не надо, K>Подставлять словари самому не надо, а писать их конечно надо (если они сами не выводятся, но и дотнете можно словари генерировать всякими костыльными способами)
Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? ))
Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов. Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.
V>>как и в С++ — всё подхватывается "само". K>В С++ подхватываться нечему, там ни параметрического полиморфизма, ни передачи словаря нет.
А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции?
Эдак тебя несет. Мы обсуждали конкретный пример, где параметрический полиморфизм времени исполнения не нужен ни разу.
K>>>Как что-то хорошее. V>>??
K>Как будто то, "что обобщенное программирование в Swift должно быть ближе к C++" — это что-то хорошее.
Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.
V>>Какая из возможностей не покрывается?
K>"Продуктивность" свертки, например. Ей нельзя управлять, просто потребляя результат (для чего итератор и нужен). Впрочем, с помощью континьюейшенов можно некий воркараунд накостылить.
Конечно, можно на продложениях или автоматах.
Есть еще способ: IoC, потреблять результат реактивным способом, управляя потреблением "где-то" в конце цепочки обработки (вызова). Непривычный для функциональщика подход, не? ))
V>>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
K>Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает.
Воооот. Именно.
А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.
Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.
K>При этом то, что решение проблемное на тот момент было известно лет 30 и лет 25 как проблемы были решены. Разумеется, этого никто не заметил, пока ручка грабель не ознакомила с ними индустриального разработчика.
Ну дело еще в том, что это выдавалось на-гора бесплатно.
И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом. Всё вместе это "платформа" для современных сложных приложений. Сиё накладывает определенный отпечаток и на "порог вхождения" и на стоимость разработки инструментария (попробуй-ка прикрути полноценный рефакторинг в Хаскель? ) и т.д. и т.п.
Поэтому тут всё как раз понятно, если не становится в позу эдакого борца-пуриста. Ей богу облом просто сыпать тонной известных до банальности аргументов, ты их и сам прекрасно знаешь. Просто поза такая, походу.
K>Проблема тут не в параметрическом полиморфизме, а в ограничении квантификации с помощью интерфейсов.
Да!
Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!
Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).
K>Но нормальное решение можно закодировать таким вот костыльным образом.
Ну да. Иначе бы я не предлагал его показать. При всей демонстрируемой тобой годами грамотности мне с трудом удаётся убедить себя, что конкретно в этой ветке ты выступил простаком. Но, похоже, именно так и есть. Без обид. ))
Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях, например:
struct Test<T> where T : struct
{
public void Func<T1>() where T1 : struct
{
Func<Test<T1>>();
}
}
Что как бы на практике появляется с фактически нулевой вероятностью. Во всех остальных случаях, хоть JIT разворачивает генерики только в рантайм, но в обычном же коде мы вызываем генерики таким образом, что компилятор может ресолвить все типы + проверяет ограничения. Т.е. коль в обычном использовании мы имеем дело только с compile-time сценарием, то те же шаблоны С++ покрывают эти сценарии... ну и покрывают дополнительно еще статические методы, операторы, "видит" внутренние типы (сколь угодно рекурсивно), т.е. много еще чего, за счет чего чуток помощнее будут.
K>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках, их разработчики же думают не о том, как обобщенный код писать, а о том, как притянуть за уши какой-нибудь треш-угар вроде "знакомого практикам" наследования или шаблонизирования/подстановки туда, где без них только лучше будет.
Ну вот мне сходу показалось, что в Swift таких воркараундов должно быть поменьше.
Здравствуйте, Ikemefula, Вы писали:
K>>Ну да, любой контейнер с Complex, а не любой контейнер с числами.
I>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
Я же тебе сразу сказал, что ты не понял всей прелести собственной задачи.
Тебе лучше внимательно читать, что именно обсуждается. ))
В твоём стиле это прекрасно делается и в Swift, аналог контейнера на С++ я уже показал. Написать тело нужного функтора оставил для самостоятельной работы. Использовались только конструкции, которые имеют полный аналог в Swift, поэтому со своими спекуляциями идешь сразу лесом.
Здравствуйте, alex_public, Вы писали:
_>Ну т.к. там llvm и есть возможность подключать библиотеки на C, то не вижу никаких проблем для кроссплатформенности, даже если Apple не захочет.
А сам компилятор кто будет писать и портировать? Он разве открытый? License: proprietary
_>Хгм, не ожидал от тебя такого вопроса. Ты же знаешь, что в том же D (да и в C++ и ещё много где) вопросы подобных контейнеров решаются в стандартной библиотеке (описание которой для Swift'a никто из нас тут ещё не видел), а не в конструкциях самого языка.
Я просто увидел вот это: http://www.weheartswift.com/higher-order-functions-map-filter-reduce-and-more/
Там говорилось, что у массивов есть map, filter, reduce и все.
_>P.S. Eсли бы в Swift'е было мощное метапрограммирование (кстати, его ещё не поздно добавить с помощью макросов) и Apple дала бы обещание поддерживать его не только под свои платформы, то на мой вкус такой язык стал бы даже поинтереснее D...
) и т.д. и т.п.
