Чому Protobuf 3 зробив усі поля повідомлень необов’язковими?

Синтаксис 3 протобуфа зробив усі поля необов’язковими для випадання ключових слів requiredта optionalпопереднього синтаксису прото2. Читаючи деякі коментарі розробників, здається, що це було зроблено для підвищення бінарної сумісності вперед / назад.

Але для мене це може бути застосовано просто версією імен пакунків, скажіть, com.example.messages.v1а потім дозвольте клієнтам впроваджувати розбираються у них десеріалізатори. Одночасно він вилучає деякі контракти, зазначені як тип, корисні з точки зору інженерії програмного забезпечення. Наприклад, якщо я маю

message Location {
   double latitude = 1;
   double longitude = 2;
}

У proto3 можна створити напівзахисну, але цілком дійсну Location, не надавши жодне з необхідних полів.

Це не великий недолік під час створення формату серіалізації на основі схеми для обміну даними між клієнтами? Чи не гірше перемістити додатковий код перевірки на кожного клієнта, перевіривши, чи всі обов'язкові поля мають дійсні значення?

proto3 вносить ряд змін, спрямованих (наскільки я розумію), щоб зробити його набагато більш корисним у кросплатформних сценаріях. Явне відстеження "призначеного" проти "не призначене, але повідомлення про значення за замовчуванням" може бути дуже важким для реалізації на деяких цільових платформах, а також може заплутати використання. Таким чином, proto3 використовує набагато простіший підхід:

• неявне значення за замовчуванням є природним нульове значення (число / перерахувань), помилкові (булеві) або порожній рядок (рядки)
• дозволений лише неявний дефолт; ніякі інші значення за замовчуванням не дозволяються
• якщо поле має це значення за замовчуванням, воно не серіалізується; не має значення, було призначено явно нулю / false / empty-string vs ніколи не призначено
• через це не існує поняття "потрібно", оскільки "явно присвоєно нульове значення" і "ніколи не присвоєне значення" виглядають ідентичними

У proto3 можна створити напівзахисне, але цілком дійсне місце розташування, не надавши жодного з необхідних полів.

Інше значення: нуль. Справа в тому, що ви явно не призначили його нулю. Бажано чи ні, це залежить від вас, але для мене це має сенс і те, як багато "ініціалізувати новий об'єкт / структуру" працює на широкому діапазоні платформ.

Чи не гірше перемістити додатковий код перевірки на кожного клієнта, перевіривши, чи всі обов'язкові поля мають дійсні значення?

Немає чого підтверджувати! Макет саме такий, який був би, якби явно було присвоєне значення нуля. Якщо це законно, то це законно. Якщо це незаконно (оскільки нуль для вас не має сенсу), це незаконно; але це було б незаконно, будь то явне чи неявне. Обсяг валідації не змінюється.

Це не великий недолік під час створення формату серіалізації на основі схеми для обміну даними між клієнтами?

Зазвичай, ні ... тим більше, що версія схеми явна. Якщо ви хочете використовувати proto2: використовуйте proto2. Нічого не змінюється автоматично.