Closed oubiwann closed 6 years ago
I'm thinking of something like this:
protobuf.core
to protobuf.core.impl.flatland.*
protobuf.core
and pull in behaviours and records for extend
from impl.*
protobuf.core.impl.flatland.core
just have a FlatlandProtoBuf
record and its corresponding behaviour def
ProtoBuf
implementation records take a compiled Java protobuf class (inner) as a field, e.g.,:
(->MyProtoBuf :protobuf-class Example$Person)
This approach would leave room for adding experimental implementations (like one based on @pyr's Mesomatic handling of protocol buffer data).
Exploration complete. See #27 for future developments.
What are the set of operations the majority of users will perform? How do these map to the current implementation? Are the function names logical and consistent? Do they seem natural for novice and expert alike? Are they all in the same namespace? Would it make sense for them to be in the same namespace? Or to provide an API namespace that pulls them from logically separate areas of the codebase?