Stream: implementers
Topic: primitive extensions
nicola (RIO/SS) (Mar 09 2017 at 15:20):
@Grahame Grieve , @Josh Mandel , @Lloyd McKenzie , @Ewout Kramer , @James Agnew I want to ask again - is extensions for primitives good idea?
I think, definition of primitive is opposite to extensibility :) What problem do we solve by this original idea?
Ewout Kramer (Mar 09 2017 at 16:08):
Yes, e.g. we have translation extensions to use on strings, I imagine you could specify the type of calender on a date, the inprecision on a decimal....
Lloyd McKenzie (Mar 09 2017 at 17:00):
Original text for a boolean. There are lots of use-cases
nicola (RIO/SS) (Mar 09 2017 at 19:01):
For me it looks like anti-pattern :( If you need extension on primitive - something wrong with design - use complex type. @Lloyd McKenzie do we have list of use cases for primitive extensions?
Lloyd McKenzie (Mar 09 2017 at 19:13):
It's an 80/20 situation. Most of the time all you need is a simple date, string, boolean, whatever. But *sometimes* you need to represent that date in another calendar. Or provide a rendered view of it. Or express it as a calculation. Or explain why it's not present. Or you need to send the string in an alternate language. So we can make them complex types all the time to allow for the possibility that edge cases exist that will require that, or we can do what we've done which is to make the "typical" case relatively painless in the wire form while still allowing for the complexity. We could dig up the list of use-cases raised when we last addressed this issue a couple of years ago. You can also look at the 10+ extensions that apply to simple types in the current extension registry. However, neither is a complete list.
Lloyd McKenzie (Mar 09 2017 at 19:13):
We certainly didn't add extensions on primitives because we were bored or thought it would create significant joy for implementers.
Lloyd McKenzie (Mar 09 2017 at 19:13):
:)
Grahame Grieve (Mar 09 2017 at 19:14):
10% of our extensions are extensions on primitives. The alternative would be to kitchen sink the primitives too
nicola (RIO/SS) (Mar 09 2017 at 19:14):
10 % is not 80 % :)
nicola (RIO/SS) (Mar 09 2017 at 19:16):
@Lloyd McKenzie additional info you described could be added just as extension, not primitive extension.
nicola (RIO/SS) (Mar 09 2017 at 19:16):
{ extension: [{url: 'dateCalendar', value:....}], date: "2017-...."}
Grahame Grieve (Mar 09 2017 at 19:21):
we certainly looked hard at that. But it has 2 genuinely big downsides:
- if you have a repeating element that is a primitive, then your extension has to repeat, and somehow link to it
- as a processor, instead of handing around just the type, that might have extensions, you have to carry around the type, and the extensions list.
Of course, in the JSON format we have now, if you work in the json directly, you get the second anyway. That's why I voted against it in the beginning.
Last updated: Apr 12 2022 at 19:14 UTC
