Это не проблема — это прямое нарушение логики. Правильно будет так: interface INamed {
name: string;
}
class MyClass implements INamed {
public name: string: 'My Class name';
}
И никаких проблем, как и нарушений логики не будет.
И да, как писали выше решается это через что-то вроде private readonly __classGuard: 'MyClass' = 'MyClass';
Это костыль, причём работоспособность его крайне сомнительна. Как минимум класс можно засунуть в неймспейс, либо импортировать под другим именем.
не думаю что это проблема конкретно тайпскрипта:
Проблема. Как минимум это ничего не даёт. А реально всё ломает, ведь в языке есть рефлекшн, декораты и много чего ещё, что позволяет как угодно менять кишки. И эта структурная типизация просто глупость, причём очень необоснованная глупость.
Тут идёт разложение объекта title(text, link) на плоский объект. Тоже самое с author(name, icon).
Например, обратите внимание на непонятно к чему относящееся свойство color
А это просто глупо.
А тут мы видим, что изначально автор использовал не-плоские объекты:
interface Story {
title: string
link: string
publishedAt: Date
author: { name: string, avatarURL: string }
}
И тут у него не возникало вопроса «а к чему относится title». В конечном итоге автор решал проблему с форматом данных в каком-то левом api и это проблемы тех, кто организовывал эти форматы.
В конечном итоге проблема решается явной типизацией/неймингом объектов. т.к. типизация в ts очень слаба, а в js нет тех же именованных аргументов — это проблема(для произвольных данных). В том же дарте мы можем написать так:
Тут также видно слабость типизации, ведь могли иметь не произвольные именованные аргументы, а произвольные типизированные аргументы(т.е. аргументы, которые выбираются исходя из типа, а не из имени), тогда бы мы просто написали:
И после этого мы явно видим дыры в логике автора, когда у него внутри тега то name, то text, то title. Это не типизация, а дыра т.к. нельзя заранее сказать «что же там написано в chillds».
В ситуации указанной автором в примере выше даже не нужны «произвольные типизированные аргументы», ведь формат сообщений/вложений фиксирован. Спокойно используется последний случай.
Ну когда у нас всякие мутабельные массивы идут всё становится сложнее. Значения добавляются, удаляются, всякие переборы этих массивов (построение diff-ов).
Никакой diff ненужен, никакой перебор не нужен. Перебор может быть нужен только тогда, когда мы оптимизирует случай упомянутый выше случай, вернее его подслучай, а именно «очень много изменений структуры в цикле» и все эти изменения перекрывают друг друга.
И именно на этом этапе и нужен diff, хотя даже тут спорно. Во-первых далеко не факт, что вся эта муть будет быстрее нативного dom, а во-вторых это целиком и полностью искусственный кейс и разбирать его не имеет смысла.
Но мой посыл выше был больше иерархию вычисляемых полей. Ну что это за проект такой, где нам не нужны computed?! Всё время есть какой-нибудь граф данных, зачастую очень большой и сложный с хитрыми переплетениями. Вот я давеча был вынужден переписать проект со Vue на React + Redux только из-за странностей трекинга зависимостей во Vue. У меня шёл счёт на несколько тысяч observables и большое древо computed-полей на основе этих obersables. Из-за особенностей vue watcher.demand мне пришлось всё снести :(
Опять рассуждения не относящиеся к теме, на которые я уже отвечал. Все эти связи существуют в нагромождениях поверх react(vdom) и будут в любом случае, если использовать этот подход.
А тут у нас вообще речь про простые get+set поля. Рассматриваем только передовую (единичные реактивные поля), забыв про тылы, и наслаждаемся тем, как же быстро работает setAttribute минуя vDom. Осталось только маску сварщика с головы снять и оглянуться… )
Любая нода это и есть get/set и больше ничего. А все ваши попытки говорить о чём-то ещё — это попытки уйти с обсуждаемой темы, на тему проблем дефолтных подходов. Т.е. говорить о теме в доступных(привычных) вам понятиях, т.к. за рамками оных вы теряетесь.
Вы там выше писали про иерархию. Я вот так сходу-спрыгу не могу придумать, как можно построить такую очередь обновлений грамотно, чтобы не потерять наш O(1) в случае ветвлений в иерархии DOM (всякие if, else, switch, ...). По сути мы не можем в произвольном порядке накатить произвольное изменение, т.к. нужной domNode может вовсе не оказаться ещё, т.к. её изменение на её создание стоит в очереди глубже. Тут надо думать… Все мои мысли приводят к циклам и падению асимптотики )
Спустя столько времени до вас наконец-то дошло(а возможно вы прочитали) проблема структуры. Только сообщаю вам, что никакая произвольная структура не нужна и эта та самая дыра в вашем понимании.
Структура вся заранее описана, структура изменяется только в очень редких случаях — 90% кейсов это массивы. Очевидно, что любая операция над тем же массивом знает то, как она его изменяет и таким образом может изменить dom-отображение.
Хотя я уже отвечал на этот вопрос, никакая иерархия dom не нужна — это рудимент, рудимент несостоятельный целиком и полностью.
Написано сумбурно, но я вижу в этом именно автоматический трекинг зависимостей. Иначе была бы формулировка вида «прописать руками в коде».
Опять подмена понятий. Автоматизированный — это не только известный вам примитивный паттерн.
Вот теперь я, несостоятельный человек, правильно понял идею?
Слишком много лишнего в понимании.
id: 'some-dom-id'
Фундаментальный проблема номер раз — хтмл-мышление, либо текст-мышление.
notifiers это руками вбитый список
Фундаментальный проблема номер два — скриптуха-мышление. Проявляется это в непонимании различий между структурой и лапшой. Структура уже существует в коде, её не нужно никак отслеживать и прочее.
В варианте Pappagento никакого трекинга нет, просто обновили переменную и поправился дом. Представьте себе, что у вас есть класс-модель, и на полях этой модели стоит сеттер, который обновляет связанную с этим полем ноду. Присваиваете значение полю — обновляется нода. Все. Никаких listeners, вдомов, ченж трекингов и т.д. (ну или можно считать что у вас вырожденный observable с не более чем одним listener).
Это бесполезно, но раз кто-то понял — я объясню нюансы. Мне лень объяснить их тем, кто целиком и полностью ничего не понимает и понимать не желает.
В данном схеме существует одна проблема, фундаментальная проблема, которую и решает vdom(на халяву) — это структура. Дело в том, что в базовом подходе данные не просто обновляют, а изменяют структуру. Тем самым может появиться значение, которое вообще ни с чем не связано.
Да, это решается построением объектов, которые сами всем этим управляют и проблем нет, но в дефолтной(обобщённой) ситуации это проблема. И если и пытаться критиковать этот подход, то именно с этой стороны.
Расскажу ещё немного про решение. Дело в том, что в дефолтном подходе некий хтмл(т.е. структура некоего поддерева) попросту захардкорена, а даже если мы использует так называемый «компонентный подход», то это мало что меняет. В конечном итоге нижняя структура первичная, а верхняя вторична.
Именно это и создаёт проблемы, но решение есть — это строить структуры данных таким образом, что они и будут представлять конечную структуру, а уже далее это будет преобразовано в ту самую dom-структуру.
По-сути реакт(и vdom в частности) и является чем-то подобным, но плохой он потому, что он экспортирует наверх структуру «под», т.е. ненужную нам структуру dom, когда мы работаем со структурами данных. Именно с преобразованием структура данных -> структура dom и возникают проблемы.
Если же наши данные сами генерируют структуру, то мы итак знаем что и куда менять. Подобные решения и используются в тех же observable структурах данных. Допустим, если мы имеем array в который мы добавили элемент, то мы из этого без всяких vdom можно вывести те операции, которые нужно произвести в dom для воспроизведения нужной структуры.
Допустим, если мы делаем push(value), то мы точно знаем, что нам нужно создать ноду и добавить её как child другой ноде, которая и представляет наш array, которая напрямую связана с array.
Тот же vdom этого сделать не может потому, что там произвольная структура(представляющая структуру dom, а не наши данные), да и вообще это несостоятельное immutable.
Все прекрасно, О1, но проблема в том, что если вы, например, в цикле совершили на модели 1000 изменений, то это вызовет 1000 апдейтов.
Проблема целиком и полностью надуманная. Но даже она имеет элементарное решение — ввод инварианта(в рамках описанного мною выше решения) одно обновление на ноду.
Если изменения будут изменять структуру, то в самом примитивном варианте туда без проблем впиливается diff. Более вменяемые решения реализуются уже для конкретных структур данных и в рамках их логики.
Я имею некоторое представление как работают разные подходы в обсуждаемом вопросе. Ни один из них не работает при помощи магии. Вот, скажем, самый необычный подход.
Я имею как минимум не меньшее представление, а про магию вам никто не говорил.
Надо рассматривать систему в комплексе.
Неверно. vdom не является комплексом.
Судя по вашему описанию выше, вы описали observable подход.
Неверно.
См. скажем, knockoutjs. А у него асимптотика «render»-а зависит не от количества dom-нод, а от сложности графа зависимостей.
Опять подмена понятий. Все графы зависимостей там существуют между данными, которые никакого отношения к render не имеют, и такие же зависимости будет с vdom и без него.
Никаких графов между dom-node и ассоциированным с ним значением/объектом — нет. И именно тут происходит подмена понятий, а именно рассуждения на тему «как связано это конечное значение и неким абстрактным состоянием приложения». Всё это не имеет отношения к делу и vdom тут никак не помогает.
И очень сильно от реализации трекинга зависимостей. Т.е. условно, при vDom у вас асимптотика O(n), а при observable aka knockoutjs у вас O(m).
Как это удобно, манипулировать а потом забывать, делая вид, что ничего не было. А ведь и там и там было O(n).
И разные константы при этом. Константа у observable большая, и сама структура, обеспечивающая такую работу — тоже.
Дак констант же нет? А теперь уже есть. И да, с чего вдруг она большая? Опять какие-то нелепые тезисы.
Там не будет O(1). Там ведь трекинг зависимостей и вся машинерия по обновлению всего, что от этих зависимостей зависит. Скажем даже простейший перебор всех listeners уже O(n).
На этом уже можно закончить, т.к. человек целиком и полностью несостоятелен. Ошибок очень много, начиная с того, что человек попытался подменить понятия, ведь в ситуации с vdom(в контексте create/diff дерева) под n понимается кол-во нод в дереве, когда как в данном случае кол-во listeners.
Заканчивая тем, что он начал спорить с голосами в голове, а не со мною, откуда-то взяв какие-то observable, которые никакого отношения к теме не имеют. Прямой биндинг подразумевает объект, который имеет лишь ссылку(и) на target, т.е. те node условное value которых привязано к value упомянутого объекта.
Утверждение является ошибочным, а причиной является неправильная трактовка назначения vdom. У vdom одна задача — поиск изменившихся нод и всё. Никакое пакетное обновление к vdom никакого отношения не имеет.
самих операций апдейта будет на десятичные порядки больше в силу того, что апдейт вам надо будет делать на каждое изменение биндинга, а не «пакетами».
Что это значит — неясно. Каким образом и из чего это следует? Я примерно предполагаю, что это какая-то смесь из нескольких популярных тезисов типа «всё дерево будет обновлять», «изменение каждой ноды(наверное имеется ввиду асинхронно) будет триггерить перерисовку, когда пакетное изменение будет триггерить одну перерисовку на пакет».
Очевидно, что первая цитата вообще несостоятельна, а вторая к vdom никакого отношения не имеет и в 10раз проще реализуется при прямом биндинге.
Если проще, то любой vdom будет пересоздаваться на каждое изменение, которых может быть сколько угодно. И даже если после этого изменения dom-node собирать в очередь и запускать пачками, то попросту мусор в сравнении с прямым биндингом.
В ситуации с прямым биндингом никакого vdom нет и на каждое изменение биндинга можно точно так же собирать операции в очередь, а далее исполнять их пачками.
Вы не поняли. Если я называю это костылём, то это не значит, что я выступаю за какую-то «декларативность». В том и проблема этих решений, что вся эта декларативность(в моём понимании) несостоятельна и причин тут много. Во-первых это очень абстрактное — нет никаких конкретных критериев для отличения одного от другого. Во-вторых сами декларации несостоятельны т.к. любой набор деклараций есть императивщина по определению.
Поэтому я вижу только одно решение — выпилить и забыть о несостоятельной декларативной концепции. И тут наши взгляды расходятся и я вам никак не помогу. Это значит, что я считаю подход jsx куда более вменяемым, нежели любые признаки текстовых шаблонов. А т.к. текстовые шаблоны несостоятельны, то все они императивны и по-сути имплементируют какой-то имеративный недоязык в рамках себя. Соответственно, любой из этих недоязыков является мене состоятельным через язык реальный, а значит язык реальный куда более подход для выражения всего того, что выражается через этот недоязык.
Боюсь если рассуждать таким образом, то состоятельных решений не существует в природе, все в чём-нибудь кривые и косые.
На чём основаны эти заявления? Каким образом из «это костыль» следует «всё костыли»? А даже если всё, то каким образом это что-то меняет? Это ведь попросту ахинея, ведь даже если всё костыли, то мы можем измерять этот уровень костыля и лучшим решением будет мене костыльное, менее кривое.
Самое смешное, что ровных поверхностей не существует в природе — что из этого следует? Я не могу что-то назвать кривым или косым?
Нет реактивных решений с O(1)
Я же уже показал O1 решение, либо вы не смогли его понять? Ну тогда объясню попроще — прямой биндинг есть O1 решение по определению. Если ещё проще, прямое изменение абстрактного value в dom-node является O1 решением.
Самое интересное, что даже если вы не понимаете назначения vdom — я рассказал об этом выше. Но даже сейчас вы этого не понимаете. Мне ещё раз рассказать, либо вы сами в состоянии изучить теме до попыток спорить?
Если вы считаете, что у вас такое решение есть, то скорее всего вы либо не понимаете bigO, либо подводные камни того или иного решения.
Я услышу основания для этих заявлений, а так же примеры подводных камней? К тому же, сами эти рассуждения несостоятельны и не имеют смысла, т.к. любой vdom является прямым биндингом и все «подводные камни»(фентезийные) присущи и vdom. И раз тут они не мешают — они не будут мешать в рамках чего-то иного.
P.S. O(n * const) = O(n)
Приравнивая одно к другому вы множите на ноль смысл vdom, т.к. он асимптотически эквивалентен dom, как и сам dom любому другому. И причина тут проста, «понимаемый» вами bigO имеет смысл только для сравнения разных асимптотик.
Глупо жаловаться на то, что вам ставят минусы. Возможно это связанно с тем, что вы вместо того, чтобы услышать людей, доказываете какую-то свою правоту:
Я слушаю людей, просто я не понимаю на что надо отвечать. Вы выкатываете мне какие-то нелепые тезисы, обвиняете меня в том, чего я не делаю. Оправдываетесь тем, что к делу отношения не имеет.
Кроме поверхностных выводов, вы статью читали (не только сам скрипт)? Вопрос стоял вполне себе конкретно: нужно было обработать один большой массив словарей
Вы опять пытаетесь выдать голоса в своей голове за мои тезисы. Про «не словари» говорил вам не я, про оптимизации говорил вам не я.
Моя претензия по поводу словарей состояла в том. Давайте я вам объясню попроще. Мы хотим сравнивать температуру чая и кофе. Как вы это делаете? Вы взяли два стакана с водой(при этом, как оказалось, разной температуры), капнули в один каплю чая, во второй каплю кофе и получили какие-то результаты. И вы пошли дальше, вы взяли не по одному, а по 4 стакана, слили их в ведро и произвели описанные выше манипуляции.
Очевидно, что человек обладающей банальной логикой сможет осознать проблему происходящего, вернее всю нелепость происходящего. Тут не нужно знать питон, С++, нужно иметь элементарный кругозор доступный любому программисту, особенно тому, который пытается что-то измерять, что-то оценивать. Ничего более я не говорил.
Т.е. вопрос звучит так. Если основная работа у вас в словарях, то зачем и для чего вы начали сравнивать вектор/питон-список? Какой в этой смысл?
(не map'ов, не структур, а конкретно словарей типа dict из Python)
Вы опять всё перепутали. Это было в другом комменте от другого человека. По поводу моих претензий — они заключались в том, что декларируя сравнения С++-вектора/питон-списка вы не сравнивали вектор/список, а сравнивали хрен пойми что.
А как работать с данными, если их нет? Даже если бы данные где-либо инициализировались до этого, то после потребовалось бы их всё равно туда складывать, поэтому задача приближена не к синтетическим тестам, а к реальной эксплуатации, то как оно реально будет использоваться.
Абсолютно нелепое заявление. В контексте сравнения вектора/списка никого не должно это интересовать. Пример со стаканами я вам привёл. К тому же, эта инициализация у вас была не идентична и даже тут вы засыпались.
Более того, основной посыл статьи чётко обозначен:
И? Это выводы основанные на несостоятельных измерениях и интерпретациях. Да и сама постановка задачи нелепа. Давайте за секунду пройдём по вектору указателей 1кк раз.
Ладно, я могу предположить, что вы не знали о том, что эта задача исполняется на порядки быстрее, а значит время отработки логики вектора в задаче единицы, доли процента. Очевидно, что если мы ускорим список в 10раз — мы ускорим программу на 10%, но это не значит, что список равен вектору и наоборот.
Тут куда не глянь везде треш. Т.е. просто непонятно как вы пришли к подобным выводам, причём тут вектор, причём тут это сравнение. Зачем говорить о векторе, а потом съезжать «нам неважно что там с вектором». Слишком сложно для меня.
Даже если мы всю реализацию переместим в C/C++ — это ничего не даст, потому что по прежнему мы будем работать в Python и оперировать его объектами.
Вы уже всю реализацию переместили в С/С++. В этом суть cython. Далее уже сравнивается нативные для С/С++ решения, либо другие решения на С/С++ созданные для питона.
Кстати, в понятие «всю» не входит никакой питон. Я могу предположить, что в cython можно реализовать какие-то модули для обычного питона и через это интегрировать их с уже существующем кодом на питоне.
Для C/C++ есть своё место здесь — вести расчёты или полностью выносить критический функционал
Где здесь? В мире питона? Ну дак вы говорили не об этом, вы утверждали, что «использование С++ ничего не даёт»(зачем вам тогда cython, если оно ничего не даёт? Или вы про ручное переписывание? Ну дак зачем в cython этот функционал? Его авторы идиоты и делают ненужно?). Теперь вы утверждаете обратное.
однако это может стоить ещё дороже
Это как в случае выше? Очень весомый аргумент.
ведь по факту, придётся делать то же, что уже реализовано целым сообществом разработчиков Python и не факт, что мы справимся лучше.
Это очень глупый тезис. Разработчики питона реализовывали логику языка питон, его примитивов и прочего. Очевидно, что для решения любой дачи не нужны эти примитивы и вы сами это подтвердили. Вы можете использовать питон-лист, а можете С++-вектор.
Мне даже не хочется обсуждать эту примитивную подмену понятий. Вы пишете код, который решает конкретную задачу и это задача не та, которую решают авторы питона. Эти задачи могут где-то пересекаться, но очень редко.
К тому же, у «разработчики С++» так же не глупые и могут написать нормальный список, нормальную мапу и прочее. Только тут нет тех ограничений, которые есть в пистоне(как и любом скриптовом языке).
Я вообще первый раз вижу питон, но посмотрев на описание pylong я увидел, что там каике-то 256битные числа(или что-то типа того). Я посмотрел на строки, которые в utf-8. Очевидно, что подобные решения удобны для некоего общего случая использования, но они чего-то стоят, они очень много стоят.
Нужны ли вам в ключах utf8? Сомневаюсь. Нужны ли вам числа шире 64бит? Сомневаюсь. И абсолютно неважно, кто является разработчиков питона — написать быстрее utf8-строки, либо 256битные числа — невозможно. Под быстрыми имеется ввиду относительно базовых.
В этом смысл С/С++-решений. Вы не платит за то, что вам ненужно. Вам нужны 256битные числа? Пожалуйста, какие угодно. Не нужны? Берите базовые и быстрее. Нужны utf8строки? Берите. Не нужны — берите быстрее базовые.
Пациент пошел ставить минусы всем моим комментам. Это настолько глупо.
Скорее выводы из этого комментария несостоятельны
Основания для этих нелепых попыток?
что цель написать не просто супероптимизировано, но так чтобы это укладывалось в рамках задачи: массив словарей.
К чему написан этот нелепый набор слов? Я где-то говорил о каких-то оптимизациях? Нет.
Если просто поотключать всё из кода, то он безусловно будет работать около 0мс, но зачем такой код нужен?
К чему написан этот нелепый набор слов? Я где-то говорил, что нужно что-то отключать? Нет. Я сообщил о несостоятельности бенчмарков и сравнения, причины были обозначены — есть что возразить — возражайте под оригинальным комментом, цитируя то, на что возражаете.
Цель же статьи не сравнить C++ и Python, а сравнить возможность и необходимость решения задачи, используя те или иные возможности C++ расширения.
К чему написан очередной нелепый набор слов? Выше мною была доказана несостоятельность как ваша, так и ваших попыток что-то сравнивать.
Ну во-первых. Тут полностью неадекватная модерация — авторы не пропускают критику, а модераторов либо нет, либо они мотивированы поступать аналогично. Поэтому, в данном случае, этой некий нейтральный(с уклоном в сторону автора) ответ призванный пройти модерацию.
Во-вторых, небезопасно это потому, что fast — это fast-math, который разрешает компилятору изменения порядка вычислений для плавучки, что небезопасно т.к. изменения порядка изменяет результаты вычислений.
но статья как чисто прикладная задача очень интересна.
Чем?
Если нужно создавать объекты — их нужно создавать (привет, К.О.), а разные сценарии работы требуют разные способы инициализации данных.
Что из этого следует и зачем это было написано? Кто-то говорил о какой-то инициализации данных? Нет.
К примеру, правильное использование Cython требует наличие головы и рук, которые должны расти хотя бы из жопы, а не в неё.
И? К чему это? Причём тут Cython?
Так что с некоторыми аргументами автора я полностью согласен: если на питоне он может это написать относительно качественно и быстро — не надо давать ему гранату, пусть и дальше пишет на питоне.
Никаких аргументов нет и небыло. Статья целиком и полностью несостоятельна — сравнение некорректно, выводы некорректны.
А ведь я не поленился. Самое интересное тут то, что питон я никогда в глаза не видел. К тому же мне непонятно — что там на С++ собрались люди писать, если они не то что С++ не знают — они даже какие-то базовые основы программирования не особо знают.
Если кратко. Я взял этот код, благо википедия помогла его запустить. Я посмотрел на два сгенерированных листинга и увидел PyDict_SetItemString и PyDict_SetItem. Далее, я загуглил PyDict_SetItemString и оказалось, что эта функция создаёт пистон-объект из си-строки. Вторая же функция принимает пистон-строку, да мало того, что пистон-строку — он ещё «кэширует» все литералы.
И что же я сделал? Сделал невозможное — поменял одно на другое. Генератор создал пистон-строку(что очевидно, т.к. в коде используется пистон-строка) и закэшировал(по принципу си) её. Всё аналогично генерации из питона.
И о чудо — test_vector стала быстрее. Т.к. у вас никаких тестов нет — проверить валидность я не смог. В любом случае несостоятельность статьи нотариально доказана.
Теперь по поводу общей глупости в статье. Ну во-первых, что измеряют эти тесты? Они измеряют вот это:
dict(
name = 'test_{}'.format(i),
test_data = i,
test_data2 = str(i),
test_data3 = range(10),
)
И это очевидно. Какое отношение бенчмарк, где создание dict занимает 99% времени измеряет оверхед на list? Никаким. И во-вторых — тут никак не сослаться на ошибку, ведь проверяется это очень просто:
Это не проблема — это прямое нарушение логики. Правильно будет так:
interface INamed {
name: string;
}
class MyClass implements INamed {
public name: string: 'My Class name';
}
И никаких проблем, как и нарушений логики не будет.
Это костыль, причём работоспособность его крайне сомнительна. Как минимум класс можно засунуть в неймспейс, либо импортировать под другим именем.
Проблема. Как минимум это ничего не даёт. А реально всё ломает, ведь в языке есть рефлекшн, декораты и много чего ещё, что позволяет как угодно менять кишки. И эта структурная типизация просто глупость, причём очень необоснованная глупость.
Вот его пример, всё находится тут:
и тут:
Тут идёт разложение объекта title(text, link) на плоский объект. Тоже самое с author(name, icon).
А это просто глупо.
А тут мы видим, что изначально автор использовал не-плоские объекты:
И тут у него не возникало вопроса «а к чему относится title». В конечном итоге автор решал проблему с форматом данных в каком-то левом api и это проблемы тех, кто организовывал эти форматы.
В конечном итоге проблема решается явной типизацией/неймингом объектов. т.к. типизация в ts очень слаба, а в js нет тех же именованных аргументов — это проблема(для произвольных данных). В том же дарте мы можем написать так:
Тут также видно слабость типизации, ведь могли иметь не произвольные именованные аргументы, а произвольные типизированные аргументы(т.е. аргументы, которые выбираются исходя из типа, а не из имени), тогда бы мы просто написали:
И после этого мы явно видим дыры в логике автора, когда у него внутри тега то name, то text, то title. Это не типизация, а дыра т.к. нельзя заранее сказать «что же там написано в chillds».
В ситуации указанной автором в примере выше даже не нужны «произвольные типизированные аргументы», ведь формат сообщений/вложений фиксирован. Спокойно используется последний случай.
Никакой diff ненужен, никакой перебор не нужен. Перебор может быть нужен только тогда, когда мы оптимизирует случай упомянутый выше случай, вернее его подслучай, а именно «очень много изменений структуры в цикле» и все эти изменения перекрывают друг друга.
И именно на этом этапе и нужен diff, хотя даже тут спорно. Во-первых далеко не факт, что вся эта муть будет быстрее нативного dom, а во-вторых это целиком и полностью искусственный кейс и разбирать его не имеет смысла.
Опять рассуждения не относящиеся к теме, на которые я уже отвечал. Все эти связи существуют в нагромождениях поверх react(vdom) и будут в любом случае, если использовать этот подход.
Любая нода это и есть get/set и больше ничего. А все ваши попытки говорить о чём-то ещё — это попытки уйти с обсуждаемой темы, на тему проблем дефолтных подходов. Т.е. говорить о теме в доступных(привычных) вам понятиях, т.к. за рамками оных вы теряетесь.
Спустя столько времени до вас наконец-то дошло(а возможно вы прочитали) проблема структуры. Только сообщаю вам, что никакая произвольная структура не нужна и эта та самая дыра в вашем понимании.
Структура вся заранее описана, структура изменяется только в очень редких случаях — 90% кейсов это массивы. Очевидно, что любая операция над тем же массивом знает то, как она его изменяет и таким образом может изменить dom-отображение.
Хотя я уже отвечал на этот вопрос, никакая иерархия dom не нужна — это рудимент, рудимент несостоятельный целиком и полностью.
Правильно, а в данном случае этим самым специально заточенным языков — является язык общего назначения.
А специально заточенным языком в общем случае будет является api на том самом языке. Да, js очень слаб для этого, но это проблема чисто js.
Очевидно, что последние.
Код не имеет смысла, проблема не имеет смысла.
Неверно. Здесь нет произвольной структуры, здесь нет структуры пляшущей от dom и нет всех этих проблем и тормозов.
К тому же, почему вдруг обновление ноды на каждый чих вообще стало является проблемой? Проблемой является перерисовка, а не обновление.
Опять подмена понятий. Автоматизированный — это не только известный вам примитивный паттерн.
Слишком много лишнего в понимании.
Фундаментальный проблема номер раз — хтмл-мышление, либо текст-мышление.
Фундаментальный проблема номер два — скриптуха-мышление. Проявляется это в непонимании различий между структурой и лапшой. Структура уже существует в коде, её не нужно никак отслеживать и прочее.
codepen.io/anon/pen/yGXOjM — минимальный пример.
Это бесполезно, но раз кто-то понял — я объясню нюансы. Мне лень объяснить их тем, кто целиком и полностью ничего не понимает и понимать не желает.
В данном схеме существует одна проблема, фундаментальная проблема, которую и решает vdom(на халяву) — это структура. Дело в том, что в базовом подходе данные не просто обновляют, а изменяют структуру. Тем самым может появиться значение, которое вообще ни с чем не связано.
Да, это решается построением объектов, которые сами всем этим управляют и проблем нет, но в дефолтной(обобщённой) ситуации это проблема. И если и пытаться критиковать этот подход, то именно с этой стороны.
Расскажу ещё немного про решение. Дело в том, что в дефолтном подходе некий хтмл(т.е. структура некоего поддерева) попросту захардкорена, а даже если мы использует так называемый «компонентный подход», то это мало что меняет. В конечном итоге нижняя структура первичная, а верхняя вторична.
Именно это и создаёт проблемы, но решение есть — это строить структуры данных таким образом, что они и будут представлять конечную структуру, а уже далее это будет преобразовано в ту самую dom-структуру.
По-сути реакт(и vdom в частности) и является чем-то подобным, но плохой он потому, что он экспортирует наверх структуру «под», т.е. ненужную нам структуру dom, когда мы работаем со структурами данных. Именно с преобразованием структура данных -> структура dom и возникают проблемы.
Если же наши данные сами генерируют структуру, то мы итак знаем что и куда менять. Подобные решения и используются в тех же observable структурах данных. Допустим, если мы имеем array в который мы добавили элемент, то мы из этого без всяких vdom можно вывести те операции, которые нужно произвести в dom для воспроизведения нужной структуры.
Допустим, если мы делаем push(value), то мы точно знаем, что нам нужно создать ноду и добавить её как child другой ноде, которая и представляет наш array, которая напрямую связана с array.
Тот же vdom этого сделать не может потому, что там произвольная структура(представляющая структуру dom, а не наши данные), да и вообще это несостоятельное immutable.
Проблема целиком и полностью надуманная. Но даже она имеет элементарное решение — ввод инварианта(в рамках описанного мною выше решения) одно обновление на ноду.
Если изменения будут изменять структуру, то в самом примитивном варианте туда без проблем впиливается diff. Более вменяемые решения реализуются уже для конкретных структур данных и в рамках их логики.
Я имею как минимум не меньшее представление, а про магию вам никто не говорил.
Неверно. vdom не является комплексом.
Неверно.
Опять подмена понятий. Все графы зависимостей там существуют между данными, которые никакого отношения к render не имеют, и такие же зависимости будет с vdom и без него.
Никаких графов между dom-node и ассоциированным с ним значением/объектом — нет. И именно тут происходит подмена понятий, а именно рассуждения на тему «как связано это конечное значение и неким абстрактным состоянием приложения». Всё это не имеет отношения к делу и vdom тут никак не помогает.
Как это удобно, манипулировать а потом забывать, делая вид, что ничего не было. А ведь и там и там было O(n).
Дак констант же нет? А теперь уже есть. И да, с чего вдруг она большая? Опять какие-то нелепые тезисы.
На этом уже можно закончить, т.к. человек целиком и полностью несостоятелен. Ошибок очень много, начиная с того, что человек попытался подменить понятия, ведь в ситуации с vdom(в контексте create/diff дерева) под n понимается кол-во нод в дереве, когда как в данном случае кол-во listeners.
Заканчивая тем, что он начал спорить с голосами в голове, а не со мною, откуда-то взяв какие-то observable, которые никакого отношения к теме не имеют. Прямой биндинг подразумевает объект, который имеет лишь ссылку(и) на target, т.е. те node условное value которых привязано к value упомянутого объекта.
Что это значит — неясно. Каким образом и из чего это следует? Я примерно предполагаю, что это какая-то смесь из нескольких популярных тезисов типа «всё дерево будет обновлять», «изменение каждой ноды(наверное имеется ввиду асинхронно) будет триггерить перерисовку, когда пакетное изменение будет триггерить одну перерисовку на пакет».
Очевидно, что первая цитата вообще несостоятельна, а вторая к vdom никакого отношения не имеет и в 10раз проще реализуется при прямом биндинге.
Если проще, то любой vdom будет пересоздаваться на каждое изменение, которых может быть сколько угодно. И даже если после этого изменения dom-node собирать в очередь и запускать пачками, то попросту мусор в сравнении с прямым биндингом.
В ситуации с прямым биндингом никакого vdom нет и на каждое изменение биндинга можно точно так же собирать операции в очередь, а далее исполнять их пачками.
Поэтому я вижу только одно решение — выпилить и забыть о несостоятельной декларативной концепции. И тут наши взгляды расходятся и я вам никак не помогу. Это значит, что я считаю подход jsx куда более вменяемым, нежели любые признаки текстовых шаблонов. А т.к. текстовые шаблоны несостоятельны, то все они императивны и по-сути имплементируют какой-то имеративный недоязык в рамках себя. Соответственно, любой из этих недоязыков является мене состоятельным через язык реальный, а значит язык реальный куда более подход для выражения всего того, что выражается через этот недоязык.
На чём основаны эти заявления? Каким образом из «это костыль» следует «всё костыли»? А даже если всё, то каким образом это что-то меняет? Это ведь попросту ахинея, ведь даже если всё костыли, то мы можем измерять этот уровень костыля и лучшим решением будет мене костыльное, менее кривое.
Самое смешное, что ровных поверхностей не существует в природе — что из этого следует? Я не могу что-то назвать кривым или косым?
Я же уже показал O1 решение, либо вы не смогли его понять? Ну тогда объясню попроще — прямой биндинг есть O1 решение по определению. Если ещё проще, прямое изменение абстрактного value в dom-node является O1 решением.
Самое интересное, что даже если вы не понимаете назначения vdom — я рассказал об этом выше. Но даже сейчас вы этого не понимаете. Мне ещё раз рассказать, либо вы сами в состоянии изучить теме до попыток спорить?
Я услышу основания для этих заявлений, а так же примеры подводных камней? К тому же, сами эти рассуждения несостоятельны и не имеют смысла, т.к. любой vdom является прямым биндингом и все «подводные камни»(фентезийные) присущи и vdom. И раз тут они не мешают — они не будут мешать в рамках чего-то иного.
Приравнивая одно к другому вы множите на ноль смысл vdom, т.к. он асимптотически эквивалентен dom, как и сам dom любому другому. И причина тут проста, «понимаемый» вами bigO имеет смысл только для сравнения разных асимптотик.
Я слушаю людей, просто я не понимаю на что надо отвечать. Вы выкатываете мне какие-то нелепые тезисы, обвиняете меня в том, чего я не делаю. Оправдываетесь тем, что к делу отношения не имеет.
Вы опять пытаетесь выдать голоса в своей голове за мои тезисы. Про «не словари» говорил вам не я, про оптимизации говорил вам не я.
Моя претензия по поводу словарей состояла в том. Давайте я вам объясню попроще. Мы хотим сравнивать температуру чая и кофе. Как вы это делаете? Вы взяли два стакана с водой(при этом, как оказалось, разной температуры), капнули в один каплю чая, во второй каплю кофе и получили какие-то результаты. И вы пошли дальше, вы взяли не по одному, а по 4 стакана, слили их в ведро и произвели описанные выше манипуляции.
Очевидно, что человек обладающей банальной логикой сможет осознать проблему происходящего, вернее всю нелепость происходящего. Тут не нужно знать питон, С++, нужно иметь элементарный кругозор доступный любому программисту, особенно тому, который пытается что-то измерять, что-то оценивать. Ничего более я не говорил.
Т.е. вопрос звучит так. Если основная работа у вас в словарях, то зачем и для чего вы начали сравнивать вектор/питон-список? Какой в этой смысл?
Вы опять всё перепутали. Это было в другом комменте от другого человека. По поводу моих претензий — они заключались в том, что декларируя сравнения С++-вектора/питон-списка вы не сравнивали вектор/список, а сравнивали хрен пойми что.
Абсолютно нелепое заявление. В контексте сравнения вектора/списка никого не должно это интересовать. Пример со стаканами я вам привёл. К тому же, эта инициализация у вас была не идентична и даже тут вы засыпались.
И? Это выводы основанные на несостоятельных измерениях и интерпретациях. Да и сама постановка задачи нелепа. Давайте за секунду пройдём по вектору указателей 1кк раз.
Ладно, я могу предположить, что вы не знали о том, что эта задача исполняется на порядки быстрее, а значит время отработки логики вектора в задаче единицы, доли процента. Очевидно, что если мы ускорим список в 10раз — мы ускорим программу на 10%, но это не значит, что список равен вектору и наоборот.
Тут куда не глянь везде треш. Т.е. просто непонятно как вы пришли к подобным выводам, причём тут вектор, причём тут это сравнение. Зачем говорить о векторе, а потом съезжать «нам неважно что там с вектором». Слишком сложно для меня.
Вы уже всю реализацию переместили в С/С++. В этом суть cython. Далее уже сравнивается нативные для С/С++ решения, либо другие решения на С/С++ созданные для питона.
Кстати, в понятие «всю» не входит никакой питон. Я могу предположить, что в cython можно реализовать какие-то модули для обычного питона и через это интегрировать их с уже существующем кодом на питоне.
Где здесь? В мире питона? Ну дак вы говорили не об этом, вы утверждали, что «использование С++ ничего не даёт»(зачем вам тогда cython, если оно ничего не даёт? Или вы про ручное переписывание? Ну дак зачем в cython этот функционал? Его авторы идиоты и делают ненужно?). Теперь вы утверждаете обратное.
Это как в случае выше? Очень весомый аргумент.
Это очень глупый тезис. Разработчики питона реализовывали логику языка питон, его примитивов и прочего. Очевидно, что для решения любой дачи не нужны эти примитивы и вы сами это подтвердили. Вы можете использовать питон-лист, а можете С++-вектор.
Мне даже не хочется обсуждать эту примитивную подмену понятий. Вы пишете код, который решает конкретную задачу и это задача не та, которую решают авторы питона. Эти задачи могут где-то пересекаться, но очень редко.
К тому же, у «разработчики С++» так же не глупые и могут написать нормальный список, нормальную мапу и прочее. Только тут нет тех ограничений, которые есть в пистоне(как и любом скриптовом языке).
Я вообще первый раз вижу питон, но посмотрев на описание pylong я увидел, что там каике-то 256битные числа(или что-то типа того). Я посмотрел на строки, которые в utf-8. Очевидно, что подобные решения удобны для некоего общего случая использования, но они чего-то стоят, они очень много стоят.
Нужны ли вам в ключах utf8? Сомневаюсь. Нужны ли вам числа шире 64бит? Сомневаюсь. И абсолютно неважно, кто является разработчиков питона — написать быстрее utf8-строки, либо 256битные числа — невозможно. Под быстрыми имеется ввиду относительно базовых.
В этом смысл С/С++-решений. Вы не платит за то, что вам ненужно. Вам нужны 256битные числа? Пожалуйста, какие угодно. Не нужны? Берите базовые и быстрее. Нужны utf8строки? Берите. Не нужны — берите быстрее базовые.
Основания для этих нелепых попыток?
К чему написан этот нелепый набор слов? Я где-то говорил о каких-то оптимизациях? Нет.
К чему написан этот нелепый набор слов? Я где-то говорил, что нужно что-то отключать? Нет. Я сообщил о несостоятельности бенчмарков и сравнения, причины были обозначены — есть что возразить — возражайте под оригинальным комментом, цитируя то, на что возражаете.
К чему написан очередной нелепый набор слов? Выше мною была доказана несостоятельность как ваша, так и ваших попыток что-то сравнивать.
Во-вторых, небезопасно это потому, что fast — это fast-math, который разрешает компилятору изменения порядка вычислений для плавучки, что небезопасно т.к. изменения порядка изменяет результаты вычислений.
Ответ несостоятелен, автор имеет ввиду march, который никого отношения к O не имеет.
Это не исходник, а неведомая портянка с хрен пойми зачем туда впихнутым Qt. При этом ладно бы core, но там gui.
Вменяемость цифр крайне сомнительна.
Тезис несостоятелен, MSVC является самым слабым компилятором — это первое. Второе, определяющим тут является качество имплементации stdlib.
Как это соотносится с:
Опять же, запустить портянку без заморочек не представляется возможным. Полезность её крайне сомнительна.
Чем?
Что из этого следует и зачем это было написано? Кто-то говорил о какой-то инициализации данных? Нет.
И? К чему это? Причём тут Cython?
Никаких аргументов нет и небыло. Статья целиком и полностью несостоятельна — сравнение некорректно, выводы некорректны.
Если кратко. Я взял этот код, благо википедия помогла его запустить. Я посмотрел на два сгенерированных листинга и увидел PyDict_SetItemString и PyDict_SetItem. Далее, я загуглил PyDict_SetItemString и оказалось, что эта функция создаёт пистон-объект из си-строки. Вторая же функция принимает пистон-строку, да мало того, что пистон-строку — он ещё «кэширует» все литералы.
И что же я сделал? Сделал невозможное — поменял одно на другое. Генератор создал пистон-строку(что очевидно, т.к. в коде используется пистон-строка) и закэшировал(по принципу си) её. Всё аналогично генерации из питона.
И о чудо — test_vector стала быстрее. Т.к. у вас никаких тестов нет — проверить валидность я не смог. В любом случае несостоятельность статьи нотариально доказана.
Теперь по поводу общей глупости в статье. Ну во-первых, что измеряют эти тесты? Они измеряют вот это:
И это очевидно. Какое отношение бенчмарк, где создание dict занимает 99% времени измеряет оверхед на list? Никаким. И во-вторых — тут никак не сослаться на ошибку, ведь проверяется это очень просто:
И о чудо — код с вектором в 3раза быстрее.
О таких «мелочах» как:
Я даже говорить не буду.
Это небезопасно.