По мне так даже оценочное суждение надо чем-то подкреплять.
По мнению автора можно всё что угодно обрамить словом "пожалуй" или "highly likely" и всё, прокатит, никто не имеет права придраться?
В нашем мире пост-правды просто очень ценятся взвешенные доказательные высказывания, хочется чтобы этого было больше. А категоричных личных оценочных суждений на на каждом углу можно найти целый мешок.
И я не имею никаких личных претензий к автору, не пытаюсь его оскорбить, наоборот, вы большой молодец, статья отличная, я думаю никто тут не хочет своей обратной связью отбить желание к дальнейшему творчеству.
Извините, но вы прямо как Никита Михалков: "Если я что-то утверждаю, я не обязан представлять доказательства".
Это же вы первый сказали что по принципу итальянской забастовки работали все советские предприятия, а вам человек ответил, что нет, не все. А вы такой "а докажи".
А я считаю раз ты первый сказал, то ты и доказывай.
А можно оффтоп-вопрос со стороны, давно меня мучает: почему в Латвии после обретения независимости автоматически не дали гражданство всем жителям?
Это же логично, я бы например на месте властей так и сделал.
Что это если не попытка отсечь от, например, избирательного права значительную часть населения?
Мне кажется это нечестная игра, и никаких нормальных оправданий тут быть не может.
Мне кажется, изначально нужно было сделать вашу либу "С++ first"а к остальным языкам наделать биндингов.
Это проверенный и многократно оправдавший себя подход.
Требование "уметь забиндиться на функцию из плюсовой либы" есть практически у любого языка программирования, это базовая вешь вообще.
Например, клинтская либа для Apache Kafka написана на С++ (librdkafka), а поверх этой плюсовой либы уже работает, например, C# обёртка (kafka-dotnet).
Таких примеров очень много.
Опять же, мне кажется при транспиляции вы будете всё время заперты в клетке — ни тебе yield, ни тебе span, вы так не будете успевать за развитием языка C# и будет всё сложнее нанимать C# програмистов с существенными ограничениями на использование фишек языка C#.
Короче, пока ещё не поздно предлагаю вам пересмотреть подход.
Новый код хотя бы начните на C++ или там Rust писать, уже толк будет.
Преимущество GraphQL над ODATA черным по-белому написано в статье
гибкость для интеграторов
Возможность точно определить необходимые вам данные
Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.
Написать batch-query в GraphQL элементарно.
Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернуть сервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.
Если вы интегрируетесь с GitHub API, это очень сильные преимущества.
API получается более простое, контракт лучше зафиксирован.
Я не гуру в java/maven, но даже у меня появился вопрос.
А можно вместо изменений в файле pom.xml + коммит в git, использовать такую вещь, как git tag.
В имени этого tag написать ровно ту версию что прописывается в pom.xml.
Преимущество tag перед commit как раз в том что он никак не меняет историю коммитов.
С помощью tag можно навесить на commit любую метаинформацию, например, версию.
А уже во время билда вытаскивать версию через этот git tag
Можно погуглить команду git describe, она примерно это и делает.
А что конкретно у вас не заработало?
У меня Clover видит и Windows и Ubuntu и MacOS.
Причём знаний у меня на уровне — скачал iso, записал в rufus на флешку, выбрал GPT при записи, поставил с флешки.
Там единственная хитрость — я запускал efi shell из clover и путь до инсталлятора ubuntu набивал руками.
что-то типа
cd FS0:
\EFI\BOOT\BOOTX64.efi
этот путь на флешке с ubuntu должен быть — запускаешь его и загружается инсталлятор ubuntu, исталлятор прописывает запись об ubuntu в EFI раздел.
Clover потом подхватывает эту запись из EFI раздела — всё работает.
Я понял что ошибался.
Реально генераторы не покрываются linq никак.
В своей работе у меня нет таких кейсов, поэтому я начал думать что yield вообще никогда не нужен.
Linq нужен для трансформаций последовательностей (map,reduce), а вот как ты последовательность нагенерируешь — это не ответственность linq, для этого как раз yield хорошо подходит.
Но я соглашусь с вами про читабельность — конкретно в этом случае она хромает.
Любая истина рождается в споре, поэтому я подкорретирую свои слова:
Если работаете с потенциально бесконечными последовательностями — только linq и никакого yield.
Если работаете с конечными, но ленивыми последовательностями (что само по себе редкий кейс), то да, yield может выглядеть читабельнее.
P.S. В вашем примере лучше всего изменить дизайн, чтобы методы были с сигнатурой вида
Неправда, внутри он написан не через yield а через честную имплементацию IEnumerable, заимствованную из кода linq, в коде в комментариях явно написано "borrowed from Linq"
Уже всё написано до нас: File.ReadLines — прекрасно работает, возвращает итератор, по итератору можно делать Skip/Take/ToList и радоваться.
Если вы хотите меня опровергнуть, то лучше вы приведите пример кода, который написан с использованием yield и который невозможно переписать с использованием linq без потери функциональности.
Объясните мне кто понял про кортежи System.ValueTuple.
С одной стороны там Item1, Item2, также как в обычном System.Tuple, с другой стороны можно дать осмысленное имя полям — Id, Name.
Вот если я напишу публичную функцию
public (long Id, string Name) GetDto(){ return (1, "1");}
А потом её зареференсю из другой сборки, то что я увижу — Item1, Item2 или же Id, Name ?
Моё мнение, что я должен увидеть Item1, Item2, потому что System.ValueTuple это struct и он не изменяем — но как тогда сохраняется семантика, что первый элемент кортежа назван Id, а второй — Name?
Кто нибудь разбирался, как это под капотом работает?
Заодно сделаем функцию конечной до int.MaxValue, а то у вас в примере если в checked всё не обернуть, то тогда после переполнения int отрицательные числа начнут возвращаться.
По мне пусть лучше функция будет конечной чем начнёт отрицательные числа возвращать или кидать Arithmetic overflow.
Я рекомендую в новом коде не использовать yield совсем, в 2016 году это как бы old style C#.
Но это далеко не всё что нужно для автоматизации open source проекта.
Что действительно нужно — так это иметь возможность билдить GitHub pull requests на Visual Studio Team Services и репортить статус обратно на GitHub используя commit status API
По мне так даже оценочное суждение надо чем-то подкреплять.
По мнению автора можно всё что угодно обрамить словом "пожалуй" или "highly likely" и всё, прокатит, никто не имеет права придраться?
В нашем мире пост-правды просто очень ценятся взвешенные доказательные высказывания, хочется чтобы этого было больше.
А категоричных личных оценочных суждений на на каждом углу можно найти целый мешок.
И я не имею никаких личных претензий к автору, не пытаюсь его оскорбить, наоборот, вы большой молодец, статья отличная, я думаю никто тут не хочет своей обратной связью отбить желание к дальнейшему творчеству.
Извините, но вы прямо как Никита Михалков: "Если я что-то утверждаю, я не обязан представлять доказательства".
Это же вы первый сказали что по принципу итальянской забастовки работали все советские предприятия, а вам человек ответил, что нет, не все.
А вы такой "а докажи".
А я считаю раз ты первый сказал, то ты и доказывай.
А можно оффтоп-вопрос со стороны, давно меня мучает: почему в Латвии после обретения независимости автоматически не дали гражданство всем жителям?
Это же логично, я бы например на месте властей так и сделал.
Что это если не попытка отсечь от, например, избирательного права значительную часть населения?
Мне кажется это нечестная игра, и никаких нормальных оправданий тут быть не может.
Согласен, если туда-сюда надо гонять много объектов, то затраты по памяти на маршаллинг могут оказаться неприемлемыми.
Зря я начал что-то советовать не разобравшись до конца в проблеме.
А вот про "сложные обёртки" не соглашусь, транспилятор так-то тоже ни разу не простая получается обёртка.
Хотел высказать своё никому не нужное мнение.
Мне кажется, изначально нужно было сделать вашу либу "С++ first"а к остальным языкам наделать биндингов.
Это проверенный и многократно оправдавший себя подход.
Требование "уметь забиндиться на функцию из плюсовой либы" есть практически у любого языка программирования, это базовая вешь вообще.
Например, клинтская либа для Apache Kafka написана на С++ (librdkafka), а поверх этой плюсовой либы уже работает, например, C# обёртка (kafka-dotnet).
Таких примеров очень много.
Опять же, мне кажется при транспиляции вы будете всё время заперты в клетке — ни тебе yield, ни тебе span, вы так не будете успевать за развитием языка C# и будет всё сложнее нанимать C# програмистов с существенными ограничениями на использование фишек языка C#.
Короче, пока ещё не поздно предлагаю вам пересмотреть подход.
Новый код хотя бы начните на C++ или там Rust писать, уже толк будет.
Судя по ажиотажу в комментариях тема не очень зашла.
Spring Cloud Config Server?
Он кажется вполне может использоваться для feature flags.
Он сам на Java, но там есть клиентская либа для .net
Зрелое решение, можно локально его развернуть.
Преимущество GraphQL над ODATA черным по-белому написано в статье
Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.
Написать batch-query в GraphQL элементарно.
Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернуть сервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.
Если вы интегрируетесь с GitHub API, это очень сильные преимущества.
API получается более простое, контракт лучше зафиксирован.
Я не гуру в java/maven, но даже у меня появился вопрос.
А можно вместо изменений в файле pom.xml + коммит в git, использовать такую вещь, как git tag.
В имени этого tag написать ровно ту версию что прописывается в pom.xml.
Преимущество tag перед commit как раз в том что он никак не меняет историю коммитов.
С помощью tag можно навесить на commit любую метаинформацию, например, версию.
А уже во время билда вытаскивать версию через этот git tag
Можно погуглить команду git describe, она примерно это и делает.
Как смотрите на такой вариант?
А что конкретно у вас не заработало?
У меня Clover видит и Windows и Ubuntu и MacOS.
Причём знаний у меня на уровне — скачал iso, записал в rufus на флешку, выбрал GPT при записи, поставил с флешки.
Там единственная хитрость — я запускал efi shell из clover и путь до инсталлятора ubuntu набивал руками.
что-то типа
cd FS0:
\EFI\BOOT\BOOTX64.efi
этот путь на флешке с ubuntu должен быть — запускаешь его и загружается инсталлятор ubuntu, исталлятор прописывает запись об ubuntu в EFI раздел.
Clover потом подхватывает эту запись из EFI раздела — всё работает.
1996 год.
В 2012 её переиздали с современной графикой — всем рекомендую.
Была новость что после линейки Cherry Trail компания Intel больше не будет делать смартфонные процессоры.
На каком процессоре будет следующая модель, если не секрет?
Я понял что ошибался.
Реально генераторы не покрываются linq никак.
В своей работе у меня нет таких кейсов, поэтому я начал думать что yield вообще никогда не нужен.
Linq нужен для трансформаций последовательностей (map,reduce), а вот как ты последовательность нагенерируешь — это не ответственность linq, для этого как раз yield хорошо подходит.
Спасибо за пример.
Тут классический случай когда мы правы оба.
Ваш пример вполне можно переписать без yield через несколько .Concat().
Но я соглашусь с вами про читабельность — конкретно в этом случае она хромает.
Любая истина рождается в споре, поэтому я подкорретирую свои слова:
Если работаете с потенциально бесконечными последовательностями — только linq и никакого yield.
Если работаете с конечными, но ленивыми последовательностями (что само по себе редкий кейс), то да, yield может выглядеть читабельнее.
P.S. В вашем примере лучше всего изменить дизайн, чтобы методы были с сигнатурой вида
И через if(Try1)...elseif(Try2) написать все вообще без yield и проверок на null.
Будет выглядеть просто и понятно.
Неправда, внутри он написан не через yield а через честную имплементацию IEnumerable, заимствованную из кода linq, в коде в комментариях явно написано "borrowed from Linq"
ссылка на ReferenceSource
Уже всё написано до нас: File.ReadLines — прекрасно работает, возвращает итератор, по итератору можно делать Skip/Take/ToList и радоваться.
Если вы хотите меня опровергнуть, то лучше вы приведите пример кода, который написан с использованием yield и который невозможно переписать с использованием linq без потери функциональности.
Объясните мне кто понял про кортежи System.ValueTuple.
С одной стороны там Item1, Item2, также как в обычном System.Tuple, с другой стороны можно дать осмысленное имя полям — Id, Name.
Вот если я напишу публичную функцию
А потом её зареференсю из другой сборки, то что я увижу — Item1, Item2 или же Id, Name ?
Моё мнение, что я должен увидеть Item1, Item2, потому что System.ValueTuple это struct и он не изменяем — но как тогда сохраняется семантика, что первый элемент кортежа назван Id, а второй — Name?
Кто нибудь разбирался, как это под капотом работает?
Моё мнение, что после появления Linq оператор yield больше не нужен.
Всё, что может сделать yield, также может сделать Linq, с сохранением всех плюшек типа ленивости вычислений.
Пример из статьи можно переписать одной строчкой.
Заодно сделаем функцию конечной до int.MaxValue, а то у вас в примере если в checked всё не обернуть, то тогда после переполнения int отрицательные числа начнут возвращаться.
По мне пусть лучше функция будет конечной чем начнёт отрицательные числа возвращать или кидать Arithmetic overflow.
Я рекомендую в новом коде не использовать yield совсем, в 2016 году это как бы old style C#.
Но это далеко не всё что нужно для автоматизации open source проекта.
Что действительно нужно — так это иметь возможность билдить GitHub pull requests на Visual Studio Team Services и репортить статус обратно на GitHub используя commit status API
В AppVeyor это есть.
Напишите отдельной статьёй когда это появится в VSTS — интереса будет намного больше чем один мой комментарий за 3 месяца.