Remove event support #880
Remove event support #880
Conversation
This removes `PbEventMixin`, `PbFieldChange`, and `EventBuffer` types, and the event plugin mixin support from the plugin. This mixin is currently not used internally and we don't want to introduce uses to it to keep the API surface small, to make it easier to make changes or migrate to another protobuf library. Fixes google#738. cl/571893384
| @@ -21,9 +21,6 @@ const GeneratedMessage_reservedNames = <String>[ | |||
| 'clone', | |||
| 'copyWith', | |||
| 'createEmptyInstance', | |||
| 'createMapField', | |||
There was a problem hiding this comment.
Perhaps we should leave these? Otherwise the names will no longer be disambiguated breaking existing code?
Not sure what is better here...
There was a problem hiding this comment.
Do you suggest we keep them indefinitely, or remove later?
If you want to remove later, this is already a breaking change so we could do it now.
There was a problem hiding this comment.
Yeah - it is either remove
- now or
- never.
Not sure what is better. We could check if we have any usages inside google3. These names are probably quite rare - so maybe it is better to remove now.
There was a problem hiding this comment.
I tested the CL globally internally it doesn't break anything.
There was a problem hiding this comment.
Ok, in that case I vote for just removing them
Leftover change from google#880.
This improves iteration performance by making `moveNext` and `current` direct calls in kernel. google#902 does not have the same effect on `moveNext` and `current` calls, this change is needed even with google#902. This change was not possible before google#880 as users could override the list and map types to types that are not `PbList`s or `PbMap`s.
This improves iteration performance by making `moveNext` and `current` direct calls in kernel. #902 does not have the same effect on `moveNext` and `current` calls, this change is needed even with #902. This change was not possible before #880 as users could override the list and map types to types that are not `PbList`s or `PbMap`s. Note: changes in the message field types (the plugin changes in this PR) are not necessary for the kernel improvements, but it doesn't hurt to generate more precise types everywhere.
Event support is currently unused internally and we don't want to introduce new
uses of it, to keep the API surface small and the library easier to update, and
to make it easier to migrate to another library.
createRepeatedFieldandcreateMapFieldexisted to support events (asPbListandPbMapdon't support this), so with the event mixin removed weremove these members as well.
Removing these members give us other opportunities: we now have full control
over the field value types. This allows, for example, refactoring
PbMapandPbListtypes for marking them as frozen without visiting the elements, whichmakes it possible to implement decoders that create frozen objects without
having to make another pass after decoding to mark every object as frozen.
Closes #738.
cl/571893384