Здравствуйте, 0x7be, Вы писали:
VD>>Не. Это называется Lisp way. А C++ way — это если что-то можно сделать через анальное отверстие, то делать именно так. А на предложение изменить язык обяснять, что религия не позволяет. 0>Ты преувеличиваешь Делание через анальное отверстие — это результат комбинации двух идей (что тоже очень С++-но по натуре): 0>1. Нежелание вводить в язык то, что можно сделать самому. 0>2. Отсутствие средств по-человечески сделать самому то, чего нет в языке. 0>
ОК. Согласен с этим определением. Но результат то тот же — все через зад.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
L>>Только не говори, что проблема в Console.WriteLine.
VD>А какая здесь проблема то? Какой-то урод написал кривую коллекцию?
Любой linq-провайдер такие коллекции отдает на раз. Предлагаешь отказаться от linq-а для доступа к базам данных?
VD>>>Есть такое простое правило нельзя принимать тип более общий чем требуется. Если оно нарушается, то можно долго искать ошибки там где их нет.
L>>Где это правило тут нарушается?
Так правило нарушается или нет?
VD>А где тут проблема? Два раза энумератор запросили что ли?
Здравствуйте, 0x7be, Вы писали:
0>Вот тут я бы с тобой поспорил. Что происходит, при замене конструкций вида foreach на вызов функций linq2objects? Повышается уровень абстракции — ты не просто делаешь foreach, а применяешь к последовательности определенные преобразования, реализация которых скрыта. В чем профит? Появление Plinq дает ответ на этот вопрос.
Фиг бы со всеми Plinq — ками. Главный профит в том, что код пишется на более высокоуровневых абстракциях. Их проще распознавать в коде, а значит проще понять что делает сам код. А Plinq и т.п. — это уже следствие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это как раз говорит о том, что программистам по сути по фигу какой там тип у этой переменной.
Программисты в большей свой части лет так дцать использовали контейнеры of Objects, кастили доставаемые из них объекты перед использованием и не видели в этом никакой проблемы. Ну по фигу им было и по сути.
Здравствуйте, Lloyd, Вы писали:
VD>>Шум ты создаешь описявая явно типы там где в этом нет смысла.
L>"там где в этом нет смысла" аннотацию типов писать нет смысла. Вы правы, кэп.
Ну, вот и консенсус. Осталось только определиться с тем где этот смысл появляется.
VD>>А переменная дает имя значению. Иногда это очень даже способствует чтению кода.
L>А иногда — нет.
Несомненно. В этом мире вообще редко встречаются правила работающие во всех без исключения случаях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>"там где в этом нет смысла" аннотацию типов писать нет смысла. Вы правы, кэп.
VD>Ну, вот и консенсус. Осталось только определиться с тем где этот смысл появляется.
Ну, я думаю, мое мнение по этому поводу достаточно очевидно.
Здравствуйте, igna, Вы писали:
VD>>Я вообще нахожу тут мало общего. В одном случае нет публичного интерфейса, в другом вывода типов.
I>И фиг с ним.
А, ну, тогда общее есть со всеми видами полиморфизма. Например, с перегрузкой методов по имени.
Есть смысл в такой общности?
I>Тем не менее твое "если мы не указываем типы внутри методов, то мы оперируем их более абстрактными интерфейсами. В эти интерфейсы входят только те методы, что были применены внутри тела метода" вполне относится и к шаблонам функций C++.
Естественно. Только от этого между шаблонами и выводом типов связи не появляется. Несомненно и то, и то виды полиморфизма.
I>Так ведь и в случае использования шаблонов C++ "типы будут проверены при компиляции и стало быть ошибок типов быть не может".
Не будут. Шаблоны или не компилируются вовсе или компилируются в некие АСТ-макросы. Проблема в том, что раскрываются эти макросы в совершенно другое время и в совершенно другом месте.
Вывод типов же гарантирует непротиворечивость кода при его компиляции. Так что тут больше общего с дженериками. Хотя и эта схожесть не дает ничего толкового.
VD>>А в случае С++ типы при разборе шаблона не проверяются вообще.
I>Ну при инстанцировании проверяются. Хрен с редькой...
Дык она может быть выполнена через 20 лет после того как код шаблона будет написан и признан корректным. А через эти 20 лет в шаблон передадут параметр который приведет к непредсказуемому результату. При чем найти источник проблем будет крайне не просто.
Так что разница как раз очень очевидная. Вывод типов безопасен (доступны проверки компилятора), удобен (работает интеллисенс, код становится компактнее и менее зашумленным) и более абстрактным (мы понимаем под типом только набор используемых членов). В случае же шаблонов С++ мы вынуждены все так же явно описывать все переменные, они не безопасны (нет гарантии что код будет корректен с любыми типами), неудобны (не работает интелисенс), но действительно абстрактен.
По моему, различий куда больше чем сходств.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
L>Так правило нарушается или нет?
Нет.
VD>>А где тут проблема? Два раза энумератор запросили что ли?
L>Да.
А это не проблема даже если энумератор на самом деле каждый раз лезет в БД. Ведь раз человек написал код таким образом, то производительность доступа к коллекции его не волнует. Иначе он просто не стал бы так писать код.
Человек обычно прекрасно понимает в каких условиях работает программа, с какими данными и какие требования предъявляются к производительности. И тут одно из двух. Или человек идиот и он будет раз за разом порождать не эффективные решения, или он адекватен и 99% кода будет приемлемого качества, а остальное придется искать с помощью профайлера. Подложить саломку на все случаи жизни невозможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Программисты в большей свой части лет так дцать использовали контейнеры of Objects, кастили доставаемые из них объекты перед использованием и не видели в этом никакой проблемы. Ну по фигу им было и по сути.
Я почему-то жил в другом мире. Ну, по фигу, так по фигу. Это их проблемы. Многие пишут на Питоне и Руби и не видят в этом проблем, хотя там почти любое вычисление — это "ксты".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
IT>>Эту кривульку лучше переписать так:
L>А как писать кривульку с DataSource-ом. Ты вроде говорил, что "у вас" эта проблема как-то решается. Как?
Ты про баиндинг? У нас для баиндинга используются специальные продвинутые списки. Так что по любому перекладывать.
var customer = GetCustomers().FirstOrDefault();
if (customer != null)
Console.WriteLine(customer.Name);
L>Код читается хуже
А теперь?
L>+ лишняя переменная. Хотя, на вкус и цвет...
Переменных абсолютно столько же. И правда у кого-то что-то с памятью.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
VD>>Ну, вот и консенсус. Осталось только определиться с тем где этот смысл появляется.
L>Ну, я думаю, мое мнение по этому поводу достаточно очевидно.
Ну, да. Очевидно не верное .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А это не проблема даже если энумератор на самом деле каждый раз лезет в БД. Ведь раз человек написал код таким образом, то производительность доступа к коллекции его не волнует. Иначе он просто не стал бы так писать код.
Ты никогда не ошибался? Тебя в реале не Чаком Норрисом зовут случаем?
VD>Человек обычно прекрасно понимает в каких условиях работает программа, с какими данными и какие требования предъявляются к производительности. И тут одно из двух. Или человек идиот и он будет раз за разом порождать не эффективные решения, или он адекватен и 99% кода будет приемлемого качества, а остальное придется искать с помощью профайлера. Подложить саломку на все случаи жизни невозможно.
Т.е. var — для тех, кто в 99% случаев не ошибается? Ну я-то явно к этой категории не отношусь.
Здравствуйте, igna, Вы писали:
I>Программисты в большей свой части лет так дцать использовали контейнеры of Objects, кастили доставаемые из них объекты перед использованием и не видели в этом никакой проблемы. Ну по фигу им было и по сути.
Подмена понятий.
Статическая и динамическая типизция это резные вещи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, igna, Вы писали:
I>Самодокументирование. Используя Stream stream = new FileStream, я сообщаю, что не использую в дальнейшем методов специфичных для FileStream.
А смысл?
Данное "самодокументирование" не делает алгоритм ни проще ни понятнее.
А то что не делает код понятнее мусор который делает код сложнее.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>>>Эту кривульку лучше переписать так:
L>>А как писать кривульку с DataSource-ом. Ты вроде говорил, что "у вас" эта проблема как-то решается. Как?
IT>Ты про баиндинг? У нас для баиндинга используются специальные продвинутые списки. Так что по любому перекладывать.
И как вы защититесь от того, что кто-то не воспользуется вашим продвинутым списком, а задействует напрямую linq-коллекцию?
Или опять будешь сказочки рассказывать про то, что у вас никто никогда не ошибается?
IT>
Здравствуйте, VladD2, Вы писали:
VD>>>Ну, вот и консенсус. Осталось только определиться с тем где этот смысл появляется.
L>>Ну, я думаю, мое мнение по этому поводу достаточно очевидно.
VD>Ну, да. Очевидно не верное .
Конечно, неверное. У меня специализация такая — создаю проблемы там где их не было, а где были — усугубляю.
Без проблем жизнь скушна.
Здравствуйте, Lloyd, Вы писали:
L>И как вы защититесь от того, что кто-то не воспользуется вашим продвинутым списком, а задействует напрямую linq-коллекцию?
Кто именно воспользуется?
L>Или опять будешь сказочки рассказывать про то, что у вас никто никогда не ошибается?
Постоянно ошибаться — это наша профессия. Я вот, например, в предыдущем предложении слово 'ошибаться' сначала без мягкого знака написал. Но потом исправился и в релиз этот текст пошёл без этой ошибки.
IT>>
Ну понятно. Оно, конечно, Any, большинству девелоперов, за которыми надо каждые три дня код проверять, понятнее будет.
L>Совсем плохо. Не скомпилится даже.
А ты попробуй. Кстати, если предыдущий код по-твоему компилировался, то в этом я добавил всего лишь одну пробельную строчку
IT>>Переменных абсолютно столько же. L>А какого лешего ты убрал customers? Там может ниже код размером с пол-"Войны и Мира", где в каждой строчке customers — по пять раз.
А зачем в этом коде этот мусор. Или ты переменные создаёшь на про запас?
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
Делание через анальное отверстие — это результат комбинации двух идей (что тоже очень С++-но по натуре):
