clang умеет давать подсказки. Находит объявления похожих символов (не знаю, какое у него ограничение на расстояние Левенштейна, но в пару символов точно находит). Естественно, не с выведенным типом, а с тем, что в исходнике написано. Если исходник не обфускан, то вполне можно догадаться.
Да, gcc и vc такого не умеют. В clang ещё и линтер какой-то более мощный встроен, чем в gcc. Сильнее докапывается до мелочей и выдаёт более понятную диагностику.
Но это фича компилятора, а не языка. Это всё равно, как мучаться с хаскеллом, используя какой-нибудь hugs вместо ghc.
clang я использовать не хочу по идеологическим соображениям - мне не нравится язык реализации, мне не нравится мой опыт работы с LLVM, мне не нравится его лицензия (она контрпродуктивна) и, последнее по счёту, но не по важности, мне не нравятся прически его создателей.
А что до ООП, тут всё просто. Отвык плюс перфекционизм. Инкрементный дизайн "быстренько наляпать под текущие нужды" - с потенциально несогласованной инициализацией, протечкой абстракции и т.п., - а потом вычищать и переделывать. Заодно и ООП освежить получится.
Вы меня перфекционистом не обзывайте. А то и ваша причёска перестанет мне нравится. ;)
Все известные мне перфекционисты объясняли перфекционизмом свои промахи в работе. От Чака Мура до... некоторых бывших коллег. Поэтому для меня это звучит, как обзывательство - "неспособный сделать хорошо".
Быстро наляпать под текущие нужды можно и нужно без ОО.
Эталонный предел маразма - давно помершая библиотечка ocaml-classes. Путем нечеловеческих усилий и ряда грязных хаков авторы таки смогли добиться существенного уменьшения функционала контейнеров стандартной библиотеки. Зато объектненько.
> Можно создавать объект пустым и заполнять его. Однако некоторые варианты заполнения могут оставлять объект в несогласованном состоянии. Стоит ли это разрешать?
Создаёшь пустым и заполняешь сколь угодно грязно и несогласовано не сам объект, а его builder или configuration. Проверку предусловий и инвариантов делаешь при создании целевого объекта в методе `Create()` строителя.
> проблемы синтаксического разбора - должен ли я бросать исключение
Исключения не нужны, по крайней мере не сразу в процесе разбора. Встретил ошибку при разборе, положил её в списочек ошибок, восстановился и пошёл разбирать дальше.
> Можно создавать объект пустым и заполнять его. Однако некоторые варианты заполнения могут оставлять объект в несогласованном состоянии. Стоит ли это разрешать?
А почему возникает такой вопрос? Вы же в haskell на создаете записи с незаполненными полями?
>Вы же в haskell на создаете записи с незаполненными полями
В Хаскеле значения, а в C++ - объекты. Значения записей могут содержать незаполненные поля, при вычислении значений которых может появиться ⊥ и это позволяет создавать согласованно заполненные записи в любом случае. Объекты с полями могут быть в несогласованном состоянии и это надо отдельно проверять, отдельно написанным кодом.
Какая разница между createModifiedInconsistentCopy :: SomeValue -> SomeArg -> SomeValue и void SomeObject::DoInconsistentModification(SomeArg) ? Просто кое-кто умеет НЕ говнокодить на хаскелле.
Конечно, в языках с указателями на неконстантные объекты - легче привести систему в неконсистентное состояние: - создать два объекта - познакомить их друг с другом (дать второму ссылку на первого) - изменить состояние одного объекта так, чтобы нарушились ожидания второго
Ну так и в хаскелле, умеючи. Только в хаскелле (и вообще в языках с неизменяемыми данными) это делается на другом механизме. Не по указателю, а по имени. - создать согласованную пару данных - передавать-передавать-передавать её - как в монаде State, скажем - где-нибудь взять и заменить один из компонентов, не проверив согласованность - передавать-передавать-передавать дальше - внезапно использовать оба компонента вместе
Изменяемые данные это неявный канал обмена информацией между частями программы.
Фразу выше перечитайте сто тысяч раз, десять тысяч раз напишите на доске мелом и тысячу раз в тетради.
Если у вас *значение*, то оно никуда не денется, если его как угодно несогласованно копировали, в отличии от объекта, которые один раз изменив несогласованно, уже трудно вернуть в согласованное состояние. Со значениями неявных каналов меньше, чем с объектами (модели актёров это тоже касается).
"Неговнокодить" с неизменными данными проще, чем с изменяемыми. Тикль проще Питона в ежедневном использовании, а с dict вообще почти мечта (если бы не hash table внутре dict, из-за которой квадратичная сложность копирования)..
Comments 66
Естественно, не с выведенным типом, а с тем, что в исходнике написано. Если исходник не обфускан, то вполне можно догадаться.
Да, gcc и vc такого не умеют.
В clang ещё и линтер какой-то более мощный встроен, чем в gcc. Сильнее докапывается до мелочей и выдаёт более понятную диагностику.
Но это фича компилятора, а не языка. Это всё равно, как мучаться с хаскеллом, используя какой-нибудь hugs вместо ghc.
Reply
clang я использовать не хочу по идеологическим соображениям - мне не нравится язык реализации, мне не нравится мой опыт работы с LLVM, мне не нравится его лицензия (она контрпродуктивна) и, последнее по счёту, но не по важности, мне не нравятся прически его создателей.
Reply
Мне-то пофиг, я под три платформы сразу собираю - вин, лин, мак - поэтому вижу весь ассортимент и зоопарк.
Reply
И, судя по услышанным словам тех поддержки, новые макбуки оказались весьма хрупкими, в отличии от старых.
Reply
Инкрементный дизайн "быстренько наляпать под текущие нужды" - с потенциально несогласованной инициализацией, протечкой абстракции и т.п., - а потом вычищать и переделывать. Заодно и ООП освежить получится.
Reply
Все известные мне перфекционисты объясняли перфекционизмом свои промахи в работе. От Чака Мура до... некоторых бывших коллег. Поэтому для меня это звучит, как обзывательство - "неспособный сделать хорошо".
Быстро наляпать под текущие нужды можно и нужно без ОО.
Reply
Reply
Reply
Путем нечеловеческих усилий и ряда грязных хаков авторы таки смогли добиться существенного уменьшения функционала контейнеров стандартной библиотеки.
Зато объектненько.
Reply
ocaml я тоже не люблю. ;)
Reply
Да; буква «S» в аббревиатуре SOLID.
> Можно создавать объект пустым и заполнять его. Однако некоторые варианты заполнения могут оставлять объект в несогласованном состоянии. Стоит ли это разрешать?
Создаёшь пустым и заполняешь сколь угодно грязно и несогласовано не сам объект, а его builder или configuration. Проверку предусловий и инвариантов делаешь при создании целевого объекта в методе `Create()` строителя.
> проблемы синтаксического разбора - должен ли я бросать исключение
Исключения не нужны, по крайней мере не сразу в процесе разбора. Встретил ошибку при разборе, положил её в списочек ошибок, восстановился и пошёл разбирать дальше.
Reply
Не люблю я ООП, очень не люблю.
Reply
Тут от языка сильно зависит. C++, конечно, требует лишних церемоний и принятия многих решений, прежде чем до функционала доберёшься: правило пяти, swap, pimpl, etc.
Reply
Reply
> Можно создавать объект пустым и заполнять его. Однако некоторые варианты заполнения могут оставлять объект в несогласованном состоянии. Стоит ли это разрешать?
А почему возникает такой вопрос? Вы же в haskell на создаете записи с незаполненными полями?
Reply
В Хаскеле значения, а в C++ - объекты. Значения записей могут содержать незаполненные поля, при вычислении значений которых может появиться ⊥ и это позволяет создавать согласованно заполненные записи в любом случае. Объекты с полями могут быть в несогласованном состоянии и это надо отдельно проверять, отдельно написанным кодом.
Reply
createModifiedInconsistentCopy :: SomeValue -> SomeArg -> SomeValue
и
void SomeObject::DoInconsistentModification(SomeArg) ?
Просто кое-кто умеет НЕ говнокодить на хаскелле.
Конечно, в языках с указателями на неконстантные объекты - легче привести систему в неконсистентное состояние:
- создать два объекта
- познакомить их друг с другом (дать второму ссылку на первого)
- изменить состояние одного объекта так, чтобы нарушились ожидания второго
Ну так и в хаскелле, умеючи.
Только в хаскелле (и вообще в языках с неизменяемыми данными) это делается на другом механизме. Не по указателю, а по имени.
- создать согласованную пару данных
- передавать-передавать-передавать её - как в монаде State, скажем
- где-нибудь взять и заменить один из компонентов, не проверив согласованность
- передавать-передавать-передавать дальше
- внезапно использовать оба компонента вместе
Reply
Изменяемые данные это неявный канал обмена информацией между частями программы.
Фразу выше перечитайте сто тысяч раз, десять тысяч раз напишите на доске мелом и тысячу раз в тетради.
Если у вас *значение*, то оно никуда не денется, если его как угодно несогласованно копировали, в отличии от объекта, которые один раз изменив несогласованно, уже трудно вернуть в согласованное состояние. Со значениями неявных каналов меньше, чем с объектами (модели актёров это тоже касается).
"Неговнокодить" с неизменными данными проще, чем с изменяемыми. Тикль проще Питона в ежедневном использовании, а с dict вообще почти мечта (если бы не hash table внутре dict, из-за которой квадратичная сложность копирования)..
Reply
Leave a comment