Приложение не должно падать от того, что в локальном хранилище, напрмиер, по любой причине оказались не те данные, которые оно ожидает.
Падать не должно, а вот получить ошибку, было бы неплохо. Оно все равно не сможет работать непонятно с чем. Как минимум было бы неплохо или флаг передать при вызове распаковки, либо колбек.(хотя это особенности реализации именно)
Правильнее всё же сперва обновить клиентов, чтобы они умели работать как со старыми типами, так и с новыми, а потом уже присылать им новые, в которых могут быть не только новые поля, но и изменение типов старых, а то и вообще их удаление.
Я говорил именно про новое, хотя удаление будет иметь ту же проблему требования одновременности. Если мы обновим все фронты, проблема не уйдет. Сопоставление сломается.
Разве что дублировать шейпы на клиентах(две регистрации на один тип, с новым полем и без), которые потом было бы неплохо и убрать.
В том и фишка, что он не требует для этого расширения.
Ну это лукавство, вы заявляли легкость расширения VaryPack, а теперь вся наша расширяемость свелась к тому что мы можем объявить свой произвольный тип на основе шейпов. (причем что регистрация типов это семантика, которой в стандарте уделено лишь одно предложение, то есть по факту это деталь реализации скорее, нежели формата как такого). Так то и в JSON/JSONB можно через другой базовый блок выразить любой тип(те же бинарные данные в JSON через Base64, неприкольно, но можно жеж).
Я не буду вдаваться в технические сравнения, тут именно про текст статьи и код с ReadMe на гите.
Для себя я делю форматы сериализации на 2 категории:
1)Без схемы - возможность прикрутить схемы не учитываем: JSON/JSONB, XML, YAML, MessagePack в schemaless режиме. По сути сообщение в таком формате несет в себе достаточно метаданных для того чтоб его можно было понять, хоть как-то.
2)Требующие схемы - без схемы полностью понять данные нельзя - MessagePack(без использования schemaless режима), ProtoBuf.
Иначе их можно назвать как документ и запись/строка(по аналогии с документно-ориентированными БД и традиционными БД)
Судя по наличию шейпов, VaryPack это первый тип, то есть документ. Плюс парадигма "прочитать любой ценой, хоть как-то", то есть реф имплементация не строгая к данным.(насчет этого позже)
Это не плохо глобально, но ограничивает области применения, особенно для языков со статической типизацией.(хотя часть из них это нюансы реализации, но она же считается эталоном, не так ли?)
Вопросы, нюансы:
По самому стандарту: Типизация по шейпам:
1)Я так понимаю, если я на бэкенде/фронте добавлю в тип Foo новое поле(и оно будет внесено в шейп), то вторая сторона перестанет создавать тип Foo а будет просто получать обычный объект?
Если да, это минус. Это уже отсутствие обратной совместимости на уровне данных, так как запрещает делать плавное обновление(часто обновление идет так, обновляются все бэкенды, чтоб начали посылать дополнительные поля, а затем только обновляем фронты, чтоб начали использовать это поле. Это важно для приложений с горизонтальным масштабированием)
2)Как зарегистрировать 2 типа с одинаковыми шейпами?(например PointF(x,y:f32) и Point(x,y:int32))
3)Поддержка наследуемых типов?
В сочетании стандарта и реализации
Хотелось бы увидеть пример реализации какого-то расширения(не просто кастомного типа, а именно расширения) - да, хотя бы записи того же fp128, НЕ через существующие типы(иначе это просто конверсия), а именно через расширение стандарта.
Cкорее о реализации
1)Было бы неплохо иметь возможность запрещать работу с незарегистрированными типами, так как если код ожидает увидеть объект класса Foo(с его методами), то просто POJO его сломает.
2)Связано с п1, раз уж мы работаем с типами, было бы неплохо поддерживать строгую типизацию(хотя бы на уровне того бы мы могли ограничить сразу тип корневого объекта).
Сейчас выходит мы читаем, а только потом проверяем, а то ли мы прочитали.
Хотя может я где-то пропустил?
3)Тут я не уверен, но я верно понял сериализатор это синглтон? Очень не помешает возможность создавать экземпляры с разными настройками.
Хотя опять же, если брать как чисто документ, то это не сильно нужно. Так как текущая реализация это скорее, что-то записали, что-то прочитали. Например никто не мешает сейчас передать сообщение чтоб в наш объекта класса Foo(из примера) попадет объект в поля вместо number.
Наивный компилятор (gcc, clang, g++, etc) сгенерировал бы просто пролог и эпилог, что привело бы к тому же самому сегфолту.
Эм, вы пустой main у этих компиляторов-то писали? Не припомню чтоб что-то падало.
Или вы имеете в виду вариант когда ставится ручной asm в функции?(где в документации описано что вы несёте полную ответственность за код)
По факту язык напоминает IL/IR код на текущий момент.
Но что радует сходу не заметил(читал по диагонали) выражений из разряда "моё лучше всех".
Единственное замечу, компонент LLVM все же имеет пересечение с общеизвестным проектом. И стоит переименовать, так как создаёт негативное ощущение.
А в целом, почему бы нет, js компилятор имеет право на жизнь. Хотя работы ещё очень много, пока по сути почти прямой компилятор, ещё ж оптимизации должны быть по хорошему.
Падать не должно, а вот получить ошибку, было бы неплохо. Оно все равно не сможет работать непонятно с чем. Как минимум было бы неплохо или флаг передать при вызове распаковки, либо колбек.(хотя это особенности реализации именно)
Я говорил именно про новое, хотя удаление будет иметь ту же проблему требования одновременности. Если мы обновим все фронты, проблема не уйдет. Сопоставление сломается.
Разве что дублировать шейпы на клиентах(две регистрации на один тип, с новым полем и без), которые потом было бы неплохо и убрать.
Ну это лукавство, вы заявляли легкость расширения VaryPack, а теперь вся наша расширяемость свелась к тому что мы можем объявить свой произвольный тип на основе шейпов. (причем что регистрация типов это семантика, которой в стандарте уделено лишь одно предложение, то есть по факту это деталь реализации скорее, нежели формата как такого). Так то и в JSON/JSONB можно через другой базовый блок выразить любой тип(те же бинарные данные в JSON через Base64, неприкольно, но можно жеж).
Я не буду вдаваться в технические сравнения, тут именно про текст статьи и код с ReadMe на гите.
Для себя я делю форматы сериализации на 2 категории:
1)Без схемы - возможность прикрутить схемы не учитываем: JSON/JSONB, XML, YAML, MessagePack в schemaless режиме. По сути сообщение в таком формате несет в себе достаточно метаданных для того чтоб его можно было понять, хоть как-то.
2)Требующие схемы - без схемы полностью понять данные нельзя - MessagePack(без использования schemaless режима), ProtoBuf.
Иначе их можно назвать как документ и запись/строка(по аналогии с документно-ориентированными БД и традиционными БД)
Судя по наличию шейпов, VaryPack это первый тип, то есть документ. Плюс парадигма "прочитать любой ценой, хоть как-то", то есть реф имплементация не строгая к данным.(насчет этого позже)
Это не плохо глобально, но ограничивает области применения, особенно для языков со статической типизацией.(хотя часть из них это нюансы реализации, но она же считается эталоном, не так ли?)
Вопросы, нюансы:
По самому стандарту: Типизация по шейпам:
1)Я так понимаю, если я на бэкенде/фронте добавлю в тип Foo новое поле(и оно будет внесено в шейп), то вторая сторона перестанет создавать тип Foo а будет просто получать обычный объект?
Если да, это минус. Это уже отсутствие обратной совместимости на уровне данных, так как запрещает делать плавное обновление(часто обновление идет так, обновляются все бэкенды, чтоб начали посылать дополнительные поля, а затем только обновляем фронты, чтоб начали использовать это поле. Это важно для приложений с горизонтальным масштабированием)
2)Как зарегистрировать 2 типа с одинаковыми шейпами?(например PointF(x,y:f32) и Point(x,y:int32))
3)Поддержка наследуемых типов?
В сочетании стандарта и реализации
Хотелось бы увидеть пример реализации какого-то расширения(не просто кастомного типа, а именно расширения) - да, хотя бы записи того же fp128, НЕ через существующие типы(иначе это просто конверсия), а именно через расширение стандарта.
Cкорее о реализации
1)Было бы неплохо иметь возможность запрещать работу с незарегистрированными типами, так как если код ожидает увидеть объект класса Foo(с его методами), то просто POJO его сломает.
2)Связано с п1, раз уж мы работаем с типами, было бы неплохо поддерживать строгую типизацию(хотя бы на уровне того бы мы могли ограничить сразу тип корневого объекта).
Сейчас выходит мы читаем, а только потом проверяем, а то ли мы прочитали.
Хотя может я где-то пропустил?
3)Тут я не уверен, но я верно понял сериализатор это синглтон? Очень не помешает возможность создавать экземпляры с разными настройками.
Хотя опять же, если брать как чисто документ, то это не сильно нужно. Так как текущая реализация это скорее, что-то записали, что-то прочитали. Например никто не мешает сейчас передать сообщение чтоб в наш объекта класса Foo(из примера) попадет объект в поля вместо number.
Забавно, что на хабре вы размер округлили вниз, а на NPM/Github округлили вверх.
Ну и сравнивать совместимость пока у вашего стандарта ровно одна реализация это кощунство ИМХО.
Так тут на Хабре тоже бывало уже. последний случай сняли с публикации.(там был чек лист нейронки по требованиям, до этого еще не вырезанные куски от нейронки)
Имя бренда VS Имя юр лица.
Я бы понимаю если запустили древний Java2ME Doom RPG(он пошаговый) чисто через чат бота.
Ну это новость звучит скорее как "Мы научились открывать WebView из телеграмма".
Ну давайте честно, нет там изменений на 100ГБ, тут виновата уже упаковка ассетов в архивы, там реально может 1 байт поменяться.
K8s это сокращение от Kubernetes, 8 означает количество опущенных букв.
Вроде на ASP.NET Core уже переехали. Но не факт что сам конечный бэк не умеет, может прокси или защита.
Частично уже
Это похоже на бесплатную модель с OpenRouter. (точнее бесплатное API скорее)
S25U, вчера обновил прошивку, ничего не установилось, в "Законе" мессенджера нет, есть просто ВК Мессенджер. Либо А/Б тестирование, либо что-то не то.
Недавно купил S25U, несколько приложений из "рекомендаций" сразу начало устанавливаться, удалились штатно вполне.
А они там что-то хитрят, скорее всего потому что используют какое-то старое или недокументированное API, я после этого сразу снес нафиг.
Ибо очень странное поведение.
Эм, вы пустой main у этих компиляторов-то писали? Не припомню чтоб что-то падало.
Или вы имеете в виду вариант когда ставится ручной asm в функции?(где в документации описано что вы несёте полную ответственность за код)
По факту язык напоминает IL/IR код на текущий момент.
Но что радует сходу не заметил(читал по диагонали) выражений из разряда "моё лучше всех".
Единственное замечу, компонент LLVM все же имеет пересечение с общеизвестным проектом. И стоит переименовать, так как создаёт негативное ощущение.
А в целом, почему бы нет, js компилятор имеет право на жизнь. Хотя работы ещё очень много, пока по сути почти прямой компилятор, ещё ж оптимизации должны быть по хорошему.
А можете рассказать как это должен быть?
Просто блок переменных?
тут все на линуксе делалось.
Хорошая попытка ПИК, но нет.
При этом в телеграмме один из последних постов про продажу устройств.
Плюс как бы реклама бренда.
Это репозиторий дашбордов, а не самого движка.