Ещё показалось, что CONTRACT будет уязвим к ошибкам неосторожных модификаций, если используется формат без сохранения типов полей. Если по глупости модифицировал класс, поменяв типы полей, а при чтении старого файла попадётся поле другой размерности, то его ведь не удастся корерктн осчитать и будут испорчены все последующие поля. Либо так, либо сохраняется очень много служебных данных (столько же, сколько и в любом другом формате с сохранением типов полей, это не претензия к библиотеке, просто констатация факта). Когда выгружаешь большие объёмы данных, хочется и размер объекта сократить и плюшки не потерять. Обычно это делается как раз отдельным сохранением scheme или тому подобного в отдельном файле или прям в этом же. И вот стало интересно, как у CONTRACT с этим дела обстоят, можно ли разметку класса сохранить отдельно и при сохранении каждого поля объекта чтобы типы полей не сохранять? Раз есть обход всех полей класса, наверное, всё это можно закостылить внутри адаптера с сохранением типов в отдельный файл.
Пока что уровня понимания хватает только на то, что вместо версионности объекта следует делать отдельные версии объекта с последующей внешней конвертацией при необходимости. То есть делать Class_v1, Class_v2, Class_v3, а не изменять один и тот же Class с течением времени.
То есть, если нужна версионность, то поле версии надо самостоятельно добавить, как обычный член класса и необходимое поведение реализовать в адаптере, в первую очередь проверяя это поле? Но мне показалось, что тут киллер-фича, что адаптер универсален и пишется один раз. Написал адаптер для какого-то формата (пусть json), передаёшь в него любые объекты с заданным CONTRACT и он их сохраняет-загружает.
Пример... Вопрос возник сам-собой, как самая первая очевидная мысль, без конкретного примера. Допустим, бинарный формат. Была какая-то переменная во float и её заменили на double. Или, ещё лучше, был int32, потом его заменили на int64, а потом заменили вообще на текстовый BCD. И надо уметь считать все три версии сохранённых данных. Из БД или из файла сохранения игры, например. Откуда-то, куда данные могут быть прочитаны спустя месяцы и годы обновлений.
Даже если в прямом эфире записать и сразу же прочитать, например, при передаче данных между устройствами, но на которых установлены разные версии приложения. Когда улиентское приложение ещё старое, а сервер уже новый и блокировать работу клиента до получения обновления не хочется...
И не забываем про игру в долгую. Жулик мог создать фейк и выложить реальные версии без изменений, чтобы все поверили, а потом выложит 1.9.9е с вирусом, например.
Даже когда flowseal вернёт аккаунт на гитхабе, новые верси сперва надо будет через virus total прогнать, потому что не будет 100% вероятности, что это правда именно Flowseal аккаунт себе вернул.
По идее, если всем этим функциям добавлять аттрибут [[nodiscard]] , то проигнорировать ошибку будет сложнее. С другой стороны, там же value() берётся, а на ошибку проверить могут и забыть...
Можно. То ли стандартными настройками, т ли через реестр руками, то ли "Шампунем". Не помню. Раньше отключал, но после последней переустанвоки не выключал и уже забыл, как отключить.
А у меня как раз обратная проблема, что постоянно НЕ исчезают! И приходится ещё раз мышкой наводить, чтобы после этого исчезло. Бесит жутко, уже почти готов отключить превьюшки, но они бывают полезными и не хочется выключать.
Так я и привёл для "чего-то". Что во всех этих произведениях ЯКОБЫ они могут терраформировать другие планеты, при этом не могут терраформирвоать Землю, хотя это дожно быть горазо быстрее и дешевле, ведь даже лететь никуда не надо.
Я же написал, что в КОНКРЕТНЫХ фильмах, КОНКРЕТНЫЙ сюжет, что Землю загрязнили до непригодного состояния. Рождаемость в Китае никак не повлияет на сюжет уже снятых блокбастеров или написанных фантастических книг.
Перечитай внимательнее. Я говорю о ситуации, что Земля всё. Ценность ноль, жизнь кончилась, всё оставшееся человечество сбегает терраформировать другие Миры.
Землю бы для начала научились терраформировать. Почему-то в куче науч-попа сюжет строится на том, что Землю загрязнили настолько, что стало невозможно жить и полетели терраформировать другие планеты. Хотя очевидно, что если не смогли Землю терраформировать до гуманоид-френдли состояния (что-то немножко вернуть как было), то прочие планеты тем более не получится (с нуля сделать хорошо из плохо).
Да, это догадка, но сделанная не мною. Я вообще повторил чужую догадку, основанную на том, что раньше пользователи делали много запросов за дёшево, а теперь получается делать мало за дорого.
Подписка и есть спонсорство, когда купил подписку за 100 денег, а запросов делал на несколько тысяч.
Раньше ИИ спонсировалось за их же счёт. Вы покупали токенов на 100 долларов, а тратили на тысячи. С недавних пор спонсорство прекратили и потребитель платит за всё реально сожжённое.
Мне особенно нравится термин "сжигание токенов". Если KPI - количество сжигаемого, то вся работа будет ориенирована на сжигание, а не на выполнение полезной работы.
Потому что проще сделать и извиниться, чем спрашивать разрешение.
Ещё показалось, что CONTRACT будет уязвим к ошибкам неосторожных модификаций, если используется формат без сохранения типов полей. Если по глупости модифицировал класс, поменяв типы полей, а при чтении старого файла попадётся поле другой размерности, то его ведь не удастся корерктн осчитать и будут испорчены все последующие поля. Либо так, либо сохраняется очень много служебных данных (столько же, сколько и в любом другом формате с сохранением типов полей, это не претензия к библиотеке, просто констатация факта). Когда выгружаешь большие объёмы данных, хочется и размер объекта сократить и плюшки не потерять. Обычно это делается как раз отдельным сохранением scheme или тому подобного в отдельном файле или прям в этом же. И вот стало интересно, как у CONTRACT с этим дела обстоят, можно ли разметку класса сохранить отдельно и при сохранении каждого поля объекта чтобы типы полей не сохранять? Раз есть обход всех полей класса, наверное, всё это можно закостылить внутри адаптера с сохранением типов в отдельный файл.
Пока что уровня понимания хватает только на то, что вместо версионности объекта следует делать отдельные версии объекта с последующей внешней конвертацией при необходимости. То есть делать Class_v1, Class_v2, Class_v3, а не изменять один и тот же Class с течением времени.
То есть, если нужна версионность, то поле версии надо самостоятельно добавить, как обычный член класса и необходимое поведение реализовать в адаптере, в первую очередь проверяя это поле? Но мне показалось, что тут киллер-фича, что адаптер универсален и пишется один раз. Написал адаптер для какого-то формата (пусть json), передаёшь в него любые объекты с заданным CONTRACT и он их сохраняет-загружает.
Пример... Вопрос возник сам-собой, как самая первая очевидная мысль, без конкретного примера. Допустим, бинарный формат. Была какая-то переменная во float и её заменили на double. Или, ещё лучше, был int32, потом его заменили на int64, а потом заменили вообще на текстовый BCD. И надо уметь считать все три версии сохранённых данных. Из БД или из файла сохранения игры, например. Откуда-то, куда данные могут быть прочитаны спустя месяцы и годы обновлений.
Даже если в прямом эфире записать и сразу же прочитать, например, при передаче данных между устройствами, но на которых установлены разные версии приложения. Когда улиентское приложение ещё старое, а сервер уже новый и блокировать работу клиента до получения обновления не хочется...
Я правильно понял, что нет поддержки версионности объектов? Это очень сильно ограничивает применимость, несмотря на все очевидные плюсы.
К статье стоит добавить, что в одном QR коде можно сохранить менее 3 килобайт бинарных данных.
И не забываем про игру в долгую. Жулик мог создать фейк и выложить реальные версии без изменений, чтобы все поверили, а потом выложит 1.9.9е с вирусом, например.
Даже когда flowseal вернёт аккаунт на гитхабе, новые верси сперва надо будет через virus total прогнать, потому что не будет 100% вероятности, что это правда именно Flowseal аккаунт себе вернул.
По идее, если всем этим функциям добавлять аттрибут
[[nodiscard]] , то проигнорировать ошибку будет сложнее. С другой стороны, там же value() берётся, а на ошибку проверить могут и забыть...А у меня тоже выключен, а превьюшки есть. Бесполезный гугл-ИИ-поиск опять соврал.
У меня OpenShell.
В Вин10 это часть Aero Peek. Advanced System Settings ➔ Performance Options ➔ uncheck Enable Peek.
загугли "windows taskbar hide thumbnails",
Можно. То ли стандартными настройками, т ли через реестр руками, то ли "Шампунем". Не помню. Раньше отключал, но после последней переустанвоки не выключал и уже забыл, как отключить.
А у меня как раз обратная проблема, что постоянно НЕ исчезают! И приходится ещё раз мышкой наводить, чтобы после этого исчезло. Бесит жутко, уже почти готов отключить превьюшки, но они бывают полезными и не хочется выключать.
Так я и привёл для "чего-то". Что во всех этих произведениях ЯКОБЫ они могут терраформировать другие планеты, при этом не могут терраформирвоать Землю, хотя это дожно быть горазо быстрее и дешевле, ведь даже лететь никуда не надо.
Я же написал, что в КОНКРЕТНЫХ фильмах, КОНКРЕТНЫЙ сюжет, что Землю загрязнили до непригодного состояния. Рождаемость в Китае никак не повлияет на сюжет уже снятых блокбастеров или написанных фантастических книг.
А теперь перечитай ещё раз, но ещё более внимательно.
Перечитай внимательнее. Я говорю о ситуации, что Земля всё. Ценность ноль, жизнь кончилась, всё оставшееся человечество сбегает терраформировать другие Миры.
Землю бы для начала научились терраформировать. Почему-то в куче науч-попа сюжет строится на том, что Землю загрязнили настолько, что стало невозможно жить и полетели терраформировать другие планеты. Хотя очевидно, что если не смогли Землю терраформировать до гуманоид-френдли состояния (что-то немножко вернуть как было), то прочие планеты тем более не получится (с нуля сделать хорошо из плохо).
Потому что так сказал блогер в ютуб-шортсе. Он выглядел солидно, ему можно верить. У него была борода.
Да, это догадка, но сделанная не мною. Я вообще повторил чужую догадку, основанную на том, что раньше пользователи делали много запросов за дёшево, а теперь получается делать мало за дорого.
Подписка и есть спонсорство, когда купил подписку за 100 денег, а запросов делал на несколько тысяч.
Раньше ИИ спонсировалось за их же счёт. Вы покупали токенов на 100 долларов, а тратили на тысячи. С недавних пор спонсорство прекратили и потребитель платит за всё реально сожжённое.
Мне особенно нравится термин "сжигание токенов". Если KPI - количество сжигаемого, то вся работа будет ориенирована на сжигание, а не на выполнение полезной работы.