• Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ
    +1
    undefined behavior пускай и зафиксированное тестами

    Это как вообще возможно?

  • Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ
    0
    Потому я и указал TDrivenD/TLastD что бы не нарваться на формализм.

    Я ж не знал, как вы TLD расшифровываете. Я подумал, что это TLeadD.


    Кстати отсутствие атомарных тестов зачастую приводит к кровавому легаси.

    Не знаю, что такое "атомарные" тесты, но написать код так, чтобы он проходил один тест, но не проходил остальные, обычно сложно и бессмысленно.


    Ежели мы касаемся вопросов оптимизации — то «преждевременная оптимизация — зло (с)».

    Дьявол в слове "преждевременная". Архитектурная оптимизация должна выполняется как можно раньше, так как потом менять её будет сложно или даже невозможно. Это, кстати, большое заблуждение, что можно не думать о скорости, пока петух не клюнет.


    Другое дело что вы не сможете их удалить если у вас нарушен OCP, что приведет вас к кровавому легаси.

    Ко кровавому легаси приводит отсутствие регулярного рефакторинга. А OCP явно запрещает рефакторинг. OCP полезен лишь при взаимодействии со внешними клиентами, когда нужно сохранять обратную совместимость.


    Везде где есть нарушение LSP — начинается задница и борьба с иерархиями.

    Не, вы не поняли суть проблемы. Смотрите, Cat является подтипом Animal, Cat[] является подтипом Animal[]. И если мы только читаем, то мы можем где угодно вместо Animal[] передать Cat[]. Но если мы где-то помещаем в массив, например, Dog, то, внезапно, мы уже не можем передавать Cat[] вместо Animal[]. Во времена Барбары об этой проблеме ещё не думали.

  • Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ
    0

    Как вы реализуете DOM с его Node, Element, HTMLElement и тд реализующими довольно развесистый API?

  • Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ
    0

    Однако, если ширина равна высоте, то это прямоугольник является ещё и квадратом.

  • Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ
    –1

    TDD предполагает написание красного теста до изменений в коде. Что приводит либо к недопокрытию, из-за невозможности написать красный тест. Либо к нарушению TDD с написанием изначально зелёного теста, что говорит о том, что он пишется после имплементации тестируемой им функциональности.


    TDD замедляет и усложняет RnD, требуя фиксации интерфейса до полного понимания какой он должен быть и реализуем ли вообще.


    SRP приводит ко кратному увеличению числа объектов, что даёт излишнюю нагрузку на GC. А это критично, когда число объектов исчисляется сотнями тысяч.


    OCP приводит к протуханию кодовой базы, переполнению её устаревшими реализациями, устаревших интерфейсов.


    LSP говорит лишь про ковариантность типов, однако в ряде случаев типы должны быть контравариантны, а в ряде инвариантны.


    ISP приводит к интерфейсам состоящим из одного метода, что нивелирует смысл интерфейсов и приводит к огромным объёмам бойлерплейта и необходимости дополнительно декларировать каждый используемый метод стороннего объекта.


    DIP затрудняет навигацию по коду, усложняет API объекта, приводит к излишнему бойлерплейту.

  • «Топологическая» сортировка графа с циклами
    0

    Я делал бандлер js модулей, где, опять же, могут быть циклические зависимости. К сожалению, просто оставить в порядке поступления — не вариант, так как поступают модули вразнобой. А, например, если исполнить модуль, расширяющий базовый класс, до модуля, где этот базовый класс определяется, то это приведёт к падению. Поэтому для каждой зависимости задаётся её вес. 0 — максимальный вес, жёсткая зависимость. минус бесконечность — самая слабая зависимость. Алгоритм получился такой: https://github.com/eigenmethod/mol/blob/master/graph/graph.ts
    cut_cycles разрезает циклы в наиболее слабом месте за O(число узлов + число связей), а sorted — сериализует ациклический граф за O(число узлов), если поменять массивы на хеш-сеты, конечно.
    У меня используется рекурсия, она ни чем не хуже ручной реализации стека так-то.
    Суть алгоритма проста: идём от узла по зависимостям в глубину, запоминая путь. Обнаружив цикл, смотрим где в пути был наименьший вес, раскручиваем стек до него, разрезаем, и переходим к следующей его зависимости. Если мы прошли по всем зависимостям узла, то помечаем его проверенным и не заходим в него больше. И так для всех узлов в качестве стартовых.

  • Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ
    0

    Скажите, какие походы в используете, и я объясню вам, почему они плохи.

  • Пишите меньше кода
    0

    А что там за история с Потапенко?

  • Пишите меньше кода
    –2

    Я же написал, что подобная настройка там не требуется, а вы со мной спорите. Видимо вы знаете про "мой" фреймворк что-то, что не знаю я.

  • Пишите меньше кода
    –3

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

  • Пишите меньше кода
    –1
    Будем считать, что внутри экшена написан такой же код.

    Так напишите этот код. Спойлер — ничего путного не получится. И приведённый в пример finder — та ещё хрень, генерирующая хрупкие селекторы.


    Говорили же сами, что все компоненты от него наследуются, так?

    Все стандартные компоненты. Вы можете от них наследоваться, а можете не наследоваться. Полиморфизм, все дела.


    Получается вы советуете мне дублировать функционал

    $mol — микромодульный конструктор, ничего дублировать не надо.


    я даже не понимаю как этот самый treeview связан с шаблоном и html вообще.

    С опытом, я надеюсь, вы отучитесь думать в терминах HTML и начнёте думать в терминах компонент и их композиции.


    Как кстати дебажить TreeView? Есть там сорсмапы или еще что-то?

    Из него генерирует тайпскриптовый класс. Читать и дебажить его вы можете как угодно.


    Честно признаюсь, я ничего не понимаю в вашем коде. Вообще.

    Возможно потому, что:


    честно признаться и не сильно интересно.

    Кому было интересно — разобрались и прониклись идеями.


    Если он это наследуется от TreeView, то все еще хуже чем я думал.

    Обычное такое опциональное переопределение.

  • Пишите меньше кода
    –2
    я попробую их прокомментировать

    К чему весь этот маркетинг с очень частым употреблением слова "очень"? Я же привёл пример кода, который получится, после реализации этой функциональности. Можете сократить — дерзайте. Не в ущерб функциональности только.


    ибо не нравится оно просто

    Устроили тут детский сад.


    Прикручивайте, причем тут фреймворк?

    А вы попишите e2e тесты, чтобы прочувствовать всю боль их поддержки, когда после очередного коммита, тесты отваливаются, потому что не находят нужного элемента или находят сразу несколько и берут первый попавшийся, или просто находят не тот элемент, но который по счастливой случайности сматчился на ваш селектор. Собственно, на главной же странице cypress можно видеть селектор по значению атрибута src у картинки. Изменили ссылку — сломались все тесты, в которых эта картинка участвовала. Вывели ещё куда-то эту картинку — получайте зелёные тесты для сломанной функциональности. В какой-то момент автотестировщикам задалбывает тратить большую часть своего рабочего времени на починку тестов. Они приходят к программистам и просят их ставить элементам уникальные идентификаторы. И тут начинается веселье с префиксами, когда один компонент есть на странице в нескольких экземплярах. В какой-то момент устаёшь писать бойлерплейт и начинаешь задумываться, что неплохо было бы автоматизировать генерацию идентификаторов. Но уже поздно, ибо на старте проекта выбрали инструмент, в котором это не автоматизировать, так как посчитали тогда, что "вам это не нужно".


    Прикручивается за 2 минуты с помощью пары хелперов.

    За 2 минуты аналитика прикручивается при автогенерации уникальных человекопонятных идентификаторов. А без них вам придётся во все вьюшки руками добавлять идентификаторы, имея всё те же проблемы, что и с тестами. С той лишь разницей, что в случае ошибки, у вас будет мусор в статистике, который вы не сможете исправить задним числом. И как с любой ручной работой ошибок будет много. И очень весело узнавать, что статистика за последние пол года накрылась медным тазом, когда ошибки всё же обнаруживаются.


    Я бы сделал общий экшн

    Далее следует код, который не понятно что и не понятно как делает. И после этого вы ещё предъявляете какие-то претензии к $mol, где кроме классов и реактивных свойств нет абсолютно ничего, ибо этих двух идиом достаточно для описания интерфейсов любой сложности.


    Добавляем экшн тем элементам тех компонентов, которые должны генерить этот «уникальный семантический идентификатор» и все.

    На основе чего он будет их генерить? Откуда он возьмёт информацию о семантике?


    А если мне вообще это не нужно?

    1. На самом деле нужно.
    2. Оно в любом случае не мешает.

    если мне нужна какая-то собственная реализация?

    Берёте и пилите свою реализацию, к $mol_view вас никто гвоздями не прибивает. В отличие от того же Svelte, где прикладной программист вообще не контролирует, как будет рендериться компонент, какой использовать шаблонизатор и тп.


    Имел ввиду конечно же $.$my_form от которого он наследуется. Думаю имеет смысл привести реализацию этого компонента. То что он «стандартный» не считается.

    Этот класс определён во view.tree
    $my_form $mol_view
        sub /
            <= First $mol_number
                value?v <=> first?v 1
            \+
            <= Second $mol_number
                value?v <=> second?v 1
            \=
            <= Result $mol_view
                sub /
                    <= result \

    Так давайте исправим это

    Реализация этого компонента не имеет значения, не подменяйте предмет обсуждения.


    всем нужны независимые микро-компоненты, которые можно собирать в разной композиции

    TodoMVC на Svelte — 8кб, на $mol — 15. Не большая разница. При этом для последнего вообще не ставилось задачи минимизировать размер бандла, ибо бандлы и так небольшими получаются.

  • Не пора ли реляционным базам данных на свалку истории?
    0

    Явно не мне, так в Ориенте первичные ключи не в хеш-таблице хранятся, а в виде grow-only массива. А вот реляционные субд вынуждены тот или иной индекс строить с соответствующей стоимостью вставки.

  • Пишите меньше кода
    0
    тем задачам, для которых подходит ангуляр

    О, я бы послушал про эти задачи.

  • Пишите меньше кода
    –2

    Вы вот вроде много слов написали, а смысл я так и не уловил. Вот где в $mol импорты/экспорты/регистрации/конфиги с отношениями?

  • Пишите меньше кода
    –2
    А точнее?

    $mol_view dom_name \input

    Не хочу специальный компонент для тега input

    Хотите копипастить одни и те же стили и поведение для каждого инпута?


    Какого компонента?

    Того, который использовался. В примере выше имя тега по умолчанию будет mol_view.


    Мне нужен просто тег input со всеми его аттрибутами.

    Вам нужна просто более быстрая лошадь.


    Стили могут быть и глобальные.

    И могут сломать сторонние виджеты. И будут грузиться, даже если на странице нет ни одного инпута.


    Оборачивать каждый HTML тег в компонент, даже если поведение тега никак не меняется

    В том-то и дело, что почти всегда меняется.

  • Пишите меньше кода
    +1

    Вводим "2e" — инпут очищается. Как пользователю ввести число "2e10"?
    Вводим "2." — инпут очищается. Как пользователю ввести число "2.1"?
    Вводим "e2" — текст остаётся в инпуте. Очень похоже на число, да.
    Вводим "--1" — текст остаётся в инпуте. Очень похоже на число, да.

  • Пишите меньше кода
    –2

    Затем, что пользователь может скопировать значение из другого места, где в выделение может попасть лишнее или используется немного иной формат. И нужно дать пользователю возможность отредактировать вставленное значение.

  • Пишите меньше кода
    0
    То есть для каждого html тега мне надо будет написать свой компонент, просто чтобы использовать его?

    1. Не обязательно, можно переопределить свойство dom_name.
    2. В большинстве случаев не нужен какой-то конкретный хтмл-элемент и вполне подходит дефолтный (по имени компонента).
    3. А даже когда нужен — всё-равно приходится писать вокруг него обёртку на любом фреймворке. Как минимум, чтобы не писать стили каждый раз заново.

    Если вам это нужно, вы всегдя можете сделать один корневой элемент,

    Это нужно почти всегда. Редкое исключение — призрачные обёртки. Но тут просто корнем выступает единственный вложенный компонент.

  • Пишите меньше кода
    0
    и комбайн отстоен, и альтернатив никаких

    А какие альтернативы вы пробовали?

  • Пишите меньше кода
    0
    Это называется "декларативность", когда описывается желаемый результат вместо процесса его получения.

    Таки логика описывает процесс получения, а не результат.


    Так вот, ваш $mol антидекларативен.

    Обоснуйте.

  • Пишите меньше кода
    0
    vintage очень часто переходит именно на такой способ написания комментариев, поэтому и был приведен в пример.

    Можете дать ссылки на примеры таких комментариев, чтобы я почитал и подумал над своим поведением?

  • Пишите меньше кода
    0
    он вам дает полезные возможности, который у вас без импорта и регистрации нет.

    MAM архитектура даёт эти возможности без ручных импортов и регистраций. Так что бойлерплейт этот весьма бесполезный.


    Нормальные фреймворки и средства разработки от этого уходят, не навязывая конкретное представления кодовой базы.
    Обычно файлвоая структура разработчику неинтересна.

    И это очень плохо, так как поощряет бардак в репозитории. Напротив, форсирование порядка, позволяет использовать это для уменьшения бойлерплейта. В частности — избавиться от импортов и регистраций.


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

  • Пишите меньше кода
    0

    Я вам по секрету скажу: NaN — тоже ложно значение в условиях.

  • Пишите меньше кода
    –1

    Элементам так или иначе придётся давать имена вручную. Ибо семантику никакая автоматика не сгенерирует.


    Идентификатор складывается из идентификатора компонента и имени элемента в нём. Так что глобальный конфликт не возможен. А локальный можно пресекать обёрткой вокруг render функции хранящей использованные в ней имена.

  • Пишите меньше кода
    0

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

  • Пишите меньше кода
    +1
    Возвращает кусок дома, описанный на jsx. Ну или прямыми вызовами.

    Это уже будет не Реакт. От слова "Вообще".

  • Пишите меньше кода
    –2

    Ну, тогда нет никаких отличий App от UI.

  • Не пора ли реляционным базам данных на свалку истории?
    0

    Ох, испортят они его..

  • Пишите меньше кода
    –2
    В Реакте я тоже так как бы могу, но в итоге получившийся код перестаёт даже отдаленно напоминать итоговый DOM.

    Есть у Реакта такой недостаток, да.


    Мало того, что код не имеет ничего общего с DOM

    Логика в принципе не может иметь ничего общего с DOM, так как DOM — это структура данных, а логика — нет.


    выглядит куда менее аккуратно чем JSX

    Что такое "аккуратно"?

  • Пишите меньше кода
    0

    Да, это целое приложение, имеющее ненулевую ценность для целевой аудитории.


    pdfjs — это библиотека, а не фреймворк.

  • Пишите меньше кода
    0

    А почему вы считаете, что роутинг и фетчинг в "application framework" должны быть, а рендерер PDF — нет?

  • Пишите меньше кода
    –2

    Лучше бы было то, что ввёл пользователь, без потери информации.

  • Пишите меньше кода
    –2
    Сравним парочку конструкций?

    Давайте сравним:


    content() {
      if( conditionA ) return this.Foo()
      if( conditionB ) return this.Bar()
      return this.Baz()
    }

    number_views() {
      return this.numbers().map( value => this.Number_view( value ) )
    }
  • Пишите меньше кода
    +1
    это позволяет надстраивать его сторонним стейт менеджментом с интересным и фичеобильным изкоробочным поведением.

    Попытки прикрутить $mol_atom2 к Реакту показали, что в процессе этого прикручивания теряются почти все фичи $mol_atom2, а сам Реакт со своим реконцилятором становится при этом пятой ногой. Так что Реакт проще выпилить, чем сделать из него что-то нормальное.

  • Пишите меньше кода
    –2
    Где короче всего завести переменную в стейте с возможностью изменения?

    a?v 0

    Это на view.tree.


    Как короче считать переменную в виде числа из поля для ввода и записать в переменную?

    $mol_number value?v <=> a?v

    Это тоже на view.tree. При этом эти два код можно и объединить:


    $mol_number value?v <=> a?v 0

    Обязательный корневой элемент шаблона увеличивает кол-во необходимых букаф?

    Как правило общий корневой дом элемент вокруг компонента необходим в целях визуализации. Так что это довольно сомнительное преимущество.

  • Пишите меньше кода
    –1
    Очевидно без роутинга, фетчинга и другие таких вещей нет

    Вот делаю я простую браузерную игрушку типа "Жизнь" — зачем мне там роутинги, фетчинги и тп?


    Angular — application framework, потому что на его основе мы можем построить не только UI, но и все приложение.

    Вот делаю я читалку PDF. Как это сделать без привлечения сторонних библиотек?

  • Пишите меньше кода
    0
    Вам ведь надо «помнить» что вызов setState() вызовет rerender + reconcile даже если {foo} не используется в шаблоне вообще!!!???

    А зачем нужно свойство, от которого не зависит визуализация?

  • Пишите меньше кода
    0
    если бы был какой-то идеоматический способ конвертировать undefined в number

    Правильный вопрос: с какого фига там вообще взялся undefined?

  • Пишите меньше кода
    –1
    Понять бы еще зачем вы все это понаписали.

    Я же написал 6 пунктов для которых всё это нужно.


    Что такое prefix? Зачем он одинаковый для обоих инпутов?

    Чтобы у каждого дом элемента был уникальный семантический идентификатор, к которому можно привязать тесты и аналитику.


    Пример на $mol вообще не содержит этих вещей.

    Потому, что фреймворк делает это всё самостоятельно, а не требует писать бойлерплейт.


    Возможно они сокрыты внутри реализации $mol_number

    Они сокрыты в $mol_view, от которого наследуются вообще все компоненты. Это тот самый рантайм, с которым "борется" Svelte.


    Неявно можно и в Svelte

    Попробуйте реализовать.


    Опять же, вы тут используете несколько готовых компонентов $mol ($my_form, $mol_view, $mol_number), не представляете детали их реализации

    $my_form — компонент, который тут собственно и создаётся.
    $mol_number — стандартный компонент. Реализацию Number для Svelte я тоже не привёл, так что всё честно.
    $mol_view — тот самый рантайм, которого в Svelte нет, и который прячет от программиста львиную долю бойлерплейта.