Как стать автором
Обновить
5
0
Галиуллин Николай @SanQri

Программист

Отправить сообщение
… и что, критерии доступности везде одинаковые?

Это в сущности не имеет значения. Могут быть и разные. Выделять подтип не обязательно.

Поэтому на самом нижнем уровне все равно должна быть проверка, и надо обрабатывать ее результаты — а поэтому, в свою очередь, проверки выше могут быть уже и лишними.

Делая проверки на низком уровне мы получим n проверок в таком случае
let variable = SomeFactory.generate();
test1ForSpecificValue(variable);
test2ForSpecificValue(variable);
...
testnForSpecificValue(variable);

Делая проверки на высоком уровне, мы сделаем одну проверку не потеряв в надежности. Код на свифте:
if let variable = SomeFactory.generate() as? SpecificType {
    test1ForSpecificValue(variable);
    test2ForSpecificValue(variable);
    ...
    testnForSpecificValue(variable);
}


Не получится, потому что компилятор не может проверить доступность пути.

Получается выстроить дизайн таким образом, что компилятор не разрешит нам собрать программу, которая будет пытаться передать файл, чья доступность не проверена, в метод, требующий доступ к файлу.
Понял. Тогда подумаю что еще можно поделать в этом мире. Не зря написал этот пост. Помимо прочего нашел по этой теме статьи у 0xd34df00d. Изучу и сделаю выводы
Спасибо, что открыли для меня название этой штуки. Вообще я пришел к идее этой статьи, как к частному от идеи обобщения Optional'ов из Swift'а. У меня появилась идея того, что оказывается называется зависимыми типами и я хотел написать на эту тему свою дипломную работу. Я пару месяцев лениво поискал язык, реализующий эту идею и не нашел. Хотя я даже не знал что писать в запрос в поисковике :)

Теперь буду знать. Не знаете языков, реализующих систему зависимых типов? Если нет, то дипломная работа по реализации такого языка всё еще актуальна.

Добавлю в начало статьи пояснение, что речь о зависимых типах с вашей ссылкой.

UPD: Вообще в программировании есть проблема в том, что вещи называются сложными именами и не понятно как их искать. Ну и плюс у каждого свое понимание одних и тех же слов, общего языка зачастую не хватает. Это видно, например, по комментариям этого поста
Никто не предлагает вам заменять каждую комбинацию полей типом. Речь о том, что такая замена возможна. Пользоваться ей стоит только тогда, когда это целесообразно. При замене мы получаем лишнюю надежность уровня компиляции и, возможно, экономию количества проверок. Платим за это количеством кода. Прибегать к выделению новой сущности или нет – зависит от ситуации.
Для каждой функции, использующей parent, понятие «валидный» будет разным

Именно! И для каждого надо определять подтип, если такая «валидность» встречается много раз. В этом на самом деле ничего страшного нет.

А компилятор как-то сможет проверить, что файл может меняться со временем независимо от кода компилируемой программы?

Не поможет, но сохранив метаданные в типе, мы не сможем передать в метод невалидные данные.
И получить взрывообразное увеличение числа типов данных.

Тип стоит заводить не всегда, а тогда, когда это поможет сократить количество валидаций и получить дополнительную надежность. Конечно, не имеет смысла делать то, что не имеет смысла…

… почему же только в ООП? Вообще везде в программировании.

Потому что про ООП часто говорят, что это моделирование систем на основе наблюдаемого мира. А так, согласен, применимо не только в ООП.
Нет, конечно, заводить новый класс для каждого метода не стоит. Идея состоит в том, чтоб избавиться от сомнений и грузить компилятор, а не разработчика. Просто иногда валидация может повторяться из раза в раз и этот факт может быть проигнорирован. Приведу пример (и, видимо, добавлю в UPD к статье).

Пусть на вход к нам поступают некоторые пути файлов. Наша система в некоторых случаях работает со всеми файлами, а в некоторых случаях только с фалами, к которым мы имеем доступ. Далее мы хотим передать их в разные подсистемы, которые так же работают как с доступными, так и с недоступными файлами. Далее эти подсистемы передают файлы еще дальше, где опять не понятно файл доступен или нет. Таким образом во всяком сомнительном месте появится проверка доступа или может напротив забудется. Из-за этого система усложнится в силу повсеместной неоднозначности и проверок. А проверки эти грузят диск и вообще тяжелые. Можно эту проверку кешировать в булевом поле, но это нас не избавит от самого факта необходимости проверки. Я предлагаю ответственность проверки переложить с разработчика на компилятор.
Речь не идет ни о какой базе и ни о каких изменениях. Просто у нас есть некоторый объект, допустим неизменяемый. Далее поведение программы зависит от подкласса, к которому он принадлежит. При этом подкласс явно не создан, а проявляется в виде соответствия некоторому логическому условию. Я призываю не плодить одинаковые проверки, а создать соответствующий подтип и продумать дизайн программы так, что методы принимают этот самый подтип, а не исходный тип. Потому что, при использовании исходного типа, мы вынуждены либо провести валидацию, либо поломаться.
Про доказательство теоремы Кнут как-то сказал: «Обратите внимание, я доказал работоспособность кода, но еще не запускал его». Так что, увы, доказательство не дает полной уверенности, но его наличие это безусловно хорошо!
С хеш таблицами это обман. Либо большой перерасход памяти, либо реальная худшая сложность О(н). Если хотите что-то быстрее, то, например, дерево Ван Эмде Боаса может отвечать на ваши запросы за логарифт по основанию w, где w это длина числа (ключа) в битах. Из-за большой константы имеет смысл использовать только на больших данных, но при этом памяти расходует сколько нужно и ведет себя более определенно по сравнению с хеш таблицами
Вы правы. Только шаблон состояние модифицирован еще и компоновщиком.
Каким образом мы понимаем какое поведение следующее, если нет родительского автомата? Вариант, в котором поведения цикла добычи дерева добавляют в очередь выполнения свое следующее поведение, мне кажется сложнее, поскольку надо будет хорошо следить за очередью выполнения, так как там могут оказаться кусочки разных поведений.

Поведение перемещения это отдельный функционал, рубка леса отдельный функционал


Это безусловно так. Они и остаются отдельными сущностями, но родительский автомат это сущность, которая определяет переходы между дочерними поведениями.

С помощью иерархического подхода, я описываю ИИ некоторых ботов. То есть даю им поведение, которое никогда не меняется. Изменяемость поведения же полезна для юнитов, контролируемых игроком.
По моему сложно сравнивать этих авторов. И все же мне больше нравится контент от Базуки :)
Не особо, дал другу перечитать перед публикацией. Много ошибок это, безусловно, плохо, но обидно, что все обращают внимание на это и никакой дискуссии около содержания статьи нет совсем.
Предположим есть 5 партий со следующим распределением голосов: 80%, 18%, 1%, 0.5: и 0.5%. Тогда у партии с 18% голосов будет около 45% голосов. Это правильно? Думаю, что все же нет.
При этом все ошибки фиксятся на кодревью
Почему в топе хабра математика первый курс без математики?
Суть статьи скорее о том, что не стоит уповать на курсы или ВУЗ, не стоит думать, что кто-то решит проблемы за тебя. Нужно действительно таки писать код, а не увиливать от этого. Я сам молод и вижу как большинство моих сверстников пишут код только в рамках обучения в ВУЗе.

… и после этого удивляемся что программист не знает элементарных основных алгоритмов и их назначений

Ну а тут можно отметить, что никто не запрещал заниматься АЦМом неким самостоятельно. Да и не всем нужны алгоритмы, на самом деле. Если человек понимает, что у него фпс проседает или пользователь ждет отклика слишком долго, то может он и разберется в чем дело, но если человек по факту верстальщик, то ему не слишком нужно это всё.

Информация

В рейтинге
Не участвует
Откуда
Одесса, Одесская обл., Украина
Дата рождения
Зарегистрирован
Активность