Вы про какой RFC? Мы же про языки с уже добавленными дженериками говорим?
Первое — это выражение new Example < A
Ха, отличная попытка использовать пример из презентации, но нет :) Example < A имеет тип boolean, в php автобоксинга нет и new bool вывалится с ошибкой. new имеет более высокий приоритет, но мне кажется вам не удастся написать валидный php код для второго случая (как минимум — переменные должны быть с $, а константы тоже в пхп хитрые)
Не вижу проблем с дженериками, есть некоторая специфика в зависимости от типа дженериков.
Первый случай некорректен всегда, даже в java. (прим: некорректен не означает ошибку)
Во втором случае не могу представить, как это сработает? Прототип функции имеет 2 аргумента, а передаётся 1.
на Go многие алгоритмы не требуется оптимизировать, чтобы получить приемлемую производительность
В общем случае это утверждение должно быть ложным, всё-таки временная сложность не зависит от языка. Полагаю, в вашем случае та самая константа сыграла решающую роль.
Ну я был со своим в Лондоне в отделении A&E (accident & emergency) — скорая, по-нашему. Мы туда приехали с мигалками, все дела. Взяли анализ крови даже. В итоге то, как я описал.
Понятно, что ибупрофен, как любое лекарство, имеет побочки — даже у парацетамола (а он вообще крайне гепатоксичный препарат и словить передозировку на нём на несколько порядков проще, чем на ибупрофене). Так что это выбор за родителями, видимо.
Как нам объяснили, если у ребёнка жар 39.6 и при этом нет других серъёзных симптомов, то сидеть дома и давать ибупрофен и/или парацетамол. Видимо более мощные антипиретики имеют гораздо больше побочек.
Парацетамол в сочетании с нурофеном могут улучшать действия друга. Плюс у детей бывает очень высокая температура и только одного препарата недостаточно из-за ограничений по суточной дозировке.
А ещё можно сделать гигантские аккумуляторы и возить их на танкерах заряжаться «грязной» дешёвой электроэнергией в страны третьего мира. «Выработка электроэнергии на аутсорс»
It is based on academic research on JSON CRDTs, but the details of the algorithm in Automerge are different from the JSON CRDT paper, and we are planning to publish more detail about it in the future.
всё-таки статья была далеко от практической реализации, будем следить за развитием событий :)
Но как вы сами отметили, это не реализация JSON, если я правильно понял — там от него осталась только возможность конвертации из RON в JSON, так что ваш пример не совсем корректен.
Интересно, как я понял они вводят отношение порядка через uuid на каждое сообщение протокола и при этом на все CRDT применяют last write wins. Честно говоря, для меня не очень понятны цели этого проекта (всё-таки они предлагают и БД свою использовать — а это довольно серьёзное ограничение), было бы интересно пообщаться с автором.
Если вам интересно узнать про попытку реализации JSON — вот тут интересная статья, но она пока ещё в теоретическом статусе.
Если мы разрешаем счётчику сходится в -1, то как же он тогда может называться неотрицательным?
Это ответ ваш вопрос «Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?»
Понимаете, в случае с (S)EC вы уже не мыслите так категорично. Я вам предложил три варианта задачи — выбирайте любую. В любой разумной постановке (я же вам привёл примеры использования) этой задачи нет простого решения. Посмотрите — сколько вариантов реализаций множества придумано, каждый со своими особенностями.
Пример — количество здоровья у игрока во время битвы или банковский счёт когда идёт несколько списаний с разных точек. Кстати интересный факт — банкоматы могут (и кое-где так и есть) выдавать деньги в условиях network partitioning.
Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?
В случае независимых декрементов наш счётчик должен сойтись в -1.
т.е. нужно средствами CRDT гарантировать, чтобы на каждой реплике было неотрицательное значение?
Это как вы пожелаете. Предлагаю вам рассмотреть несколько вариантов
1) разрешать репликам временно уходить в минус (а что тогда делать клиентам, которые получили отрицательное? Значит ли это, что герой мёртв?), если при этом гарантировать, что целевое значение сходится в неотрицательное число (а как?)
2) запрещать репликам уходить в минус
3) разрешать итоговому значению временно уходить в минус (пример с банкоматами)
Причём даже у знаменитых пилотов рунета начинается конкретный баттхёрт при намёке на это.
А есть причина, по который эти действия происходят вручную? Вроде бы нет сложностей делать это автоматически
Вы про какой RFC? Мы же про языки с уже добавленными дженериками говорим?
Ха, отличная попытка использовать пример из презентации, но нет :)
Example < A имеет тип boolean, в php автобоксинга нет и new bool вывалится с ошибкой.new имеет более высокий приоритет, но мне кажется вам не удастся написать валидный php код для второго случая (как минимум — переменные должны быть с $, а константы тоже в пхп хитрые)Первый случай некорректен всегда, даже в java. (прим: некорректен не означает ошибку)
Во втором случае не могу представить, как это сработает? Прототип функции имеет 2 аргумента, а передаётся 1.
В общем случае это утверждение должно быть ложным, всё-таки временная сложность не зависит от языка. Полагаю, в вашем случае та самая константа сыграла решающую роль.
терапевтическая доза 500-1000мг до 4х раз в день что прямо граничит с началом гепатоксического действия.
Понятно, что ибупрофен, как любое лекарство, имеет побочки — даже у парацетамола (а он вообще крайне гепатоксичный препарат и словить передозировку на нём на несколько порядков проще, чем на ибупрофене). Так что это выбор за родителями, видимо.
В пункте 7, где рассматривается эта система, даётся более чёткое определение.
Немного настораживает
всё-таки статья была далеко от практической реализации, будем следить за развитием событий :)
Но как вы сами отметили, это не реализация JSON, если я правильно понял — там от него осталась только возможность конвертации из RON в JSON, так что ваш пример не совсем корректен.
Интересно, как я понял они вводят отношение порядка через uuid на каждое сообщение протокола и при этом на все CRDT применяют last write wins. Честно говоря, для меня не очень понятны цели этого проекта (всё-таки они предлагают и БД свою использовать — а это довольно серьёзное ограничение), было бы интересно пообщаться с автором.
Если вам интересно узнать про попытку реализации JSON — вот тут интересная статья, но она пока ещё в теоретическом статусе.
Это ответ ваш вопрос «Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?»
Понимаете, в случае с (S)EC вы уже не мыслите так категорично. Я вам предложил три варианта задачи — выбирайте любую. В любой разумной постановке (я же вам привёл примеры использования) этой задачи нет простого решения. Посмотрите — сколько вариантов реализаций множества придумано, каждый со своими особенностями.
В случае независимых декрементов наш счётчик должен сойтись в -1.
Это как вы пожелаете. Предлагаю вам рассмотреть несколько вариантов
1) разрешать репликам временно уходить в минус (а что тогда делать клиентам, которые получили отрицательное? Значит ли это, что герой мёртв?), если при этом гарантировать, что целевое значение сходится в неотрицательное число (а как?)
2) запрещать репликам уходить в минус
3) разрешать итоговому значению временно уходить в минус (пример с банкоматами)