Comments 43
«Почему собака виляет хвостом? Потому что она умнее. Если бы хвост был умнее, он бы вилял собакой»
Согласен. Что бы Undo/Redo не вилял программой изначально должно быть правильное проектирование. Это я еще понял лет 8 назад когда третий раз переписывал свою прорамму (хобби было, а не что то комерческое) и начал использовать ЮМЛ — вот тогда у меня собака и стала умнее.
Первое что пришло бы в голову хранить не полные версии. Типа diff и хранить только патчи…
боюсь на каждый чих вычислять диффку проца не напасешься…
Это первое что в голову пришло, а не
>> на каждое действие сохранять состояние документа целиком
Если начать копать, то можно попытаться разбить весь текст на примитивы (позиция от и до которой произошло изменение) и уже к ним делать те же diff… Да и вообще в сторону системы контроля версий смотреть. NetBeans хранит историю на диске, вроде больших тормозов не наблюдал.
>> на каждое действие сохранять состояние документа целиком
Если начать копать, то можно попытаться разбить весь текст на примитивы (позиция от и до которой произошло изменение) и уже к ним делать те же diff… Да и вообще в сторону системы контроля версий смотреть. NetBeans хранит историю на диске, вроде больших тормозов не наблюдал.
а что происходит с перекрёстными участками. Если, например, выделен «orld» и для него применён курсив?
У GOF построение текстового редактора подробно описано в терминах паттернов, где решены все ваши проблемы. Авторы, вы их читали?
Ну а может, всё-таки вначале почитать GoF, а не давать подобные ссылки? Лично вот я вижу, что авторы данного поста пытались что-то изобрести и изобрели почти что паттерн «Команда», только кривоватый. В результате было потрачено лишнее время, а ведь гораздо быстрее можно было бы решить задачу, всего лишь прочитав GoF. Автор же гневной статьи как раз пишет, что «Design patterns are spoonfeed material for brainless programmers incapable of independent thought». Кстати, статус самих паттернов описан и у GoF, и если внимательно читать, то всё становится понятным. Ну и никто, конечно же, не мешает криворукому программеру криво использовать паттерны, как, собтвенно, никто ему же не мешает криво использовать Java, C#, Python. Но ведь никто не ругает сами языки (точнее, ругают, но на то есть совсем другие причины) и учебники по ним.
Паттерны, да, весьма зависят от того, на чём именно мы пишем. Но тут уместно говорить не о паттерне для каждого конкретного языка, а о паттерне для большой группы языков. А есть ещё и паттерны для конкретных языков или фреймворков. Ну, например, в .NET есть вроде как официальный способ «правильной» реализации метода Dispose().
И, прежде чем ругать паттерны, хочу заметить одну вещь. У любой проблемы есть достаточно много аспектов. Какие-то из них более-менее очевидны, какие-то нет. Непосредственный опыт позволяет с этими неочевидными проблемами столкнуться нос к носу. И кто-то уже сталкивался не раз. И уже предостерёг остальных от решения проблемы «не так», написав «как нужно». Ну, например, GoF. А хотите писать код, который преподнесёт в будущем немало сюрпризов и ругани — выкидывайте нафиг все книги и будьте «программистами, способными независимо мыслить». Я вас предупреждал.
Паттерны, да, весьма зависят от того, на чём именно мы пишем. Но тут уместно говорить не о паттерне для каждого конкретного языка, а о паттерне для большой группы языков. А есть ещё и паттерны для конкретных языков или фреймворков. Ну, например, в .NET есть вроде как официальный способ «правильной» реализации метода Dispose().
И, прежде чем ругать паттерны, хочу заметить одну вещь. У любой проблемы есть достаточно много аспектов. Какие-то из них более-менее очевидны, какие-то нет. Непосредственный опыт позволяет с этими неочевидными проблемами столкнуться нос к носу. И кто-то уже сталкивался не раз. И уже предостерёг остальных от решения проблемы «не так», написав «как нужно». Ну, например, GoF. А хотите писать код, который преподнесёт в будущем немало сюрпризов и ругани — выкидывайте нафиг все книги и будьте «программистами, способными независимо мыслить». Я вас предупреждал.
Жжоте, дядьки. Всё уже придумали до Вас
Прежде, чем давать ссылки неплохо было бы самому понимать для чего предназначен тот или иной паттерн. Паттерн «команда» предназначен для инкапсуляции тех или иных действий с возможностью отката или повторения этих действий. Автор же показал декомпозицию части функциональности текстового редактора на элементарные операции, т.е именно тот элементарный функционал (семантику операции), который будет выполнять тот или иной экземпляр паттерны «комманда».
изменяемый объект — это ссылка. неизменяемый — значение. а то, что вы реализовали для форматирования — ленивое копирование.
проблема вашего подхода в том, что вы накладываете довольно жёсткие ограничения на трансформации, что может быть проблемно при интеграции сторонних библиотек. например — внешний типограф, который берёт у вас текст, возвращает его изменённым, но информация об элементарных операциях теряется. подсветка синтаксиса, замена по регулярке и многое другое должно быть специально написано под ваше апи.
а вот если развить идею ленивого копирования, то можно без существенного захламления памяти сохранять снэпшоты между преобразованиями, которые каждый волен реализовывать как ему угодно. для этого документ представляется в виде неизменяемого дерева: документ состоит из глав, главы из параграфов, параграфы из предложений. если изменился 1 параграф в 1 главе, то создаётся новый документ, в него заносятся ссылки на старые главы, кроме 1, которая создаётся новая. в ней аналогично с параграфами. потребление ресурсов, конечно, больше, но уже терпимо. подстроки тоже можно лениво копировать, если что.
проблема вашего подхода в том, что вы накладываете довольно жёсткие ограничения на трансформации, что может быть проблемно при интеграции сторонних библиотек. например — внешний типограф, который берёт у вас текст, возвращает его изменённым, но информация об элементарных операциях теряется. подсветка синтаксиса, замена по регулярке и многое другое должно быть специально написано под ваше апи.
а вот если развить идею ленивого копирования, то можно без существенного захламления памяти сохранять снэпшоты между преобразованиями, которые каждый волен реализовывать как ему угодно. для этого документ представляется в виде неизменяемого дерева: документ состоит из глав, главы из параграфов, параграфы из предложений. если изменился 1 параграф в 1 главе, то создаётся новый документ, в него заносятся ссылки на старые главы, кроме 1, которая создаётся новая. в ней аналогично с параграфами. потребление ресурсов, конечно, больше, но уже терпимо. подстроки тоже можно лениво копировать, если что.
у меня похожий механизм реализован на яваскрипте для подсветки синтаксиса. текст разбивается на блоки, те снова разбиваются на блоки и так далее. при этом на каждом уровне стоит кэширование, а значит если изменился один параграф — только он и будет заново перекрашен. отслеживать элементарные операции — слишком уж проблематично.
откатов/перекатов пока нету, но думаю сделать так: берётся кэш блоков из предыдущего снэпшота, потом новый текст также фрактально разбивается на блоки и если какой-то блок встречается в кэше, то вставляется ссылка на него и его уже не разбиваем. как результат — на каждый снэпшот будет храниться только некий дифф.
при этом механизмы отката и подсветки полностью независимы и не накладывают друг на друга никаких ограничений.
откатов/перекатов пока нету, но думаю сделать так: берётся кэш блоков из предыдущего снэпшота, потом новый текст также фрактально разбивается на блоки и если какой-то блок встречается в кэше, то вставляется ссылка на него и его уже не разбиваем. как результат — на каждый снэпшот будет храниться только некий дифф.
при этом механизмы отката и подсветки полностью независимы и не накладывают друг на друга никаких ограничений.
Очень сильно от задачи зависит. Вот у Вас допущение, изменился один параграф, только его и перекрашиваем. Многострочные комментарии сразу идут лесом. Если в Вашей задаче это неважно, значит Вам повезло.
не идут %-) параграфы являются блоками только в тексте, а в програмном коде другие блоки и различные коментарии в частности
вот, попробуй: mojura.110mb.com/i-component/?client/main/iface/field/field.html
вот, попробуй: mojura.110mb.com/i-component/?client/main/iface/field/field.html
Если бы всё ограничивалось только текстом, то, возможно, и имело бы смысл городить огород и пытаться сделать более универсальную вещь. Но кроме текста в документе встречается много всякой всячины, например списки, картинки, таблицы, поля, букмарки и т.д. и т.п. И тут уже не затачиваясь на апи сделать ничего не получится.
В теории всё просто, читай GOF и будет тебе счастье, на практике же грабельки разложены более замысловато.
В теории всё просто, читай GOF и будет тебе счастье, на практике же грабельки разложены более замысловато.
Сборище закинутых самовлюбленных умников, получивших красные дипломы, просидев ночами за книгами и выучив их все наизусть, каждый из который старается опустить других и продемонстрировать объемы своего головного мозга, не нагруженного больше ничем кроме заученными книгами и всепоглащающами мыслями о самовозвышении и блядском унижении других.
фуф, извините, наболело )
фуф, извините, наболело )
а в чём проблема со списками таблицами и прочей лабудой? идея представления документа в виде неизменяемого дерева со ссылками на блоки данных — универсальна.
дай ссылку на это чтиво
дай ссылку на это чтиво
Дело в том, что те же таблицы лежат не в дереве, а в параллельной структуре, которая «опирается» на дерево (ссылается на его узлы). И сама таблица имеет структуру не совсем уж примитивную. А букмарки вообще представляют собой именованный диапазон документа. Причем начинаться или заканчиваться он запросто может прямо посреди run. Списки и стили тоже в своей иерархии лежат, из узлов дерева на них только косвенные ссылки есть.
К сожалению ничего краткого и ёмкого не смогу посоветовать для ознакомления, только стандарт, часть 4-я, емнип.
К сожалению ничего краткого и ёмкого не смогу посоветовать для ознакомления, только стандарт, часть 4-я, емнип.
это всего-лишь формат экспорта с его заковырками. какое он отношение имеет ко внутрненней организации данных в программе? какую задачу решают букмарки?
этот стандарт и есть тот самый гоф? о0
этот стандарт и есть тот самый гоф? о0
Формально никакого. На практике, то что в этом документе написано один в один соответствует внутренней организации данных в ворде. Отступления от этой организации, конечно, возможны, правда ведут к гемморою, например в тех же импортах/экспортах. Мы когда файлы OpenOffice читали, задолбались конвертировать его модель.
Букмарки — навигация, пометка частей документа для дальнейшей обработки.
А GoF это сюда.
Букмарки — навигация, пометка частей документа для дальнейшей обработки.
А GoF это сюда.
гомэн, это не тебе. а у тебя от чёго такой сильный баттхёрт? %-)
Это официальное отношение сотрудника компании DevExpress к аудитории Хабра?
Кстати, зачем Вы убрали информацию о компании из профиля? Ещё неделю назад была (когда был предыдущий топик про Undo/Redo от одномённой компании). Уволились, что ли? ;)
Кстати, зачем Вы убрали информацию о компании из профиля? Ещё неделю назад была (когда был предыдущий топик про Undo/Redo от одномённой компании). Уволились, что ли? ;)
К слову, Undo/Redo с блекджеком делается элементарно на immutable-объектах.
Sign up to leave a comment.
Undo/Redo — Хвост виляет собакой