Rendering Media Type with nullable primitive attribute about goa

[raphael]

Thank you for the report! do you think leveraging the "required" validation would work? i.e. with your example:

Baz := MediaType("Baz", func() {
    Attributes(func() {
        Attribute("Count", Integer)
    }
}

would generate what you want and:

Baz := MediaType("Baz", func() {
    Attributes(func() {
        Attribute("Count", Integer)
        Required("Count")
    }
}

would generate a non-pointer (what is generated today).

[rootpd]

Hi, it might work and it would make sense to use it, but I see two problems there:

• This would be a breaking change as every Media Type producer would have to change the way how he creates an instance of Media Type if it has a non-Required Attribute.
• By default, working with primitive types in Go is probably meant to be (just my personal feeling) implemented directly, not through the pointer. It doesn't feel right to me to force the pointer into the places where it might not be necessary. I would force it only where explicitly stated in the design.

Considering written, maybe the most straight-forward, non-breaking and simplest solution might be letting developer to state it the other way around. Let him state which attributes should be the pointer and keep other as they're now.

Baz := MediaType("Baz", func() {
    Attributes(func() {
        Attribute("Count", Integer)
        Pointer("Count") // I believe there is a better name for the function
    }
}

Anyway, I'm still barely new in Go so I might be wrong with my assumptions :).

[raphael]

I'm not too concerned about breaking changes at this stage, there is still work to do before v1 - it's better to avoid it but I wouldn't base the design on this requirement (yet).

As for the default not being a pointer I would agree but then again if you're saying the value is not required aren't you saying it can be nil? (and should therefore be a pointer to the value). Thanks for the discussion!

[rootpd]

If you're saying the value is not required aren't you saying it can be nil?

Yes, you're right :). That Pointer() of mine would have just been another way how to state the same.

The only point I have left is that you're not "saying it's not required". It's implicit and implicit pointer might not be so obvious/expected for general user. But maybe it's just the matter of getting used to (for me) and reading the docs or letting compiler do the check (for new users). To be honest, it was never a problem with structs, so I'm probably just fabricating issues right now :).

+1 for reusing Required()

[raphael]

Point well taken, I went with "make required explicit" rather than "make optional explicit" because that's what the JSON schema validation standard went with but that doesn't make it intuitive. Something to ponder...

[noblehng]

After this change, if I mark a String type as Required(), it will map to the string Go type. But the generated Valid() method will also throw a MissingAttributeError error, when the string is empty. This means that we can't use empty string as default value, as we usually do in Go, when the field is missing.

I think the PtrTo() way, with an addition of Indirect() for UserType to use a struct type directly, will be more idiomatic in Go.

[raphael]

What you are describing sounds like a bug, I did fix something in these lines recently, would you mind trying again with the latest?
The DSL is not Go and is not trying to be idiomatic. The generated code is. The DSL follows the JSON schema and Swagger abstractions.

[noblehng]

It bahaves the same with the latest git master.

[raphael]

Oh sorry I misread your comment. If you say that an API endpoint requires a string for a parameter then the empty string is not an acceptable value by definition. Again remember this is defining the REST API contract - not a Go function contract. Some encodings can't differentiate between null or empty.

[Tri125]

Hello,
I've stumbled across this PR while searching on how to render nullable types.
Maybe I'm missing something, but basically I've defined some media type with optional attributes, effectively making them pointers of the type.

However, when they are effectively nil, they are not rendered as null with the json view of the mediaType, they just don't appear, they aren't rendered.

[raphael]

That is indeed the default behavior. Just curious why do you need null? in most languages unmarshalling a JSON object with a null field is equivalent to unmarshalling an object without that field.

[Tri125]

I just wanted to make it clearer that a certain field exists but is empty.
The default behavior of json.Marshal in Go is to encode nil pointer as the null JSON object.

[raphael]

Make it clearer for who? the computer won't care :) it is more efficient to not send that data since the end result is the same. The behavior in Go is driven by the JSON struct tags. By default goa uses omitempty which causes the fields to not be generated. In the vast majority (all?) cases that's what you want since again there is no benefit to adding the fields and just drawbacks (performance penalty). If you really want them then you can override the tags generated by goa using metadata.

[Tri125]

I was thinking about making it clearer for developers who are going to consume the API. They might not be aware that a certain media have a certain field if it's rarely present. Sure, the problem is easily avoidable if they read the doc, but I also thought about making their life easier. However, I admit that it makes a lot of sense to omit it.

Thank you for the solution.

[raphael]

Developers should really look at the docs - not at the response to understand the API. There is much more than just the shape of the response body (which values can fields have, what is their semantic, how do they relate to each other, when will they bet set, what headers are meaningful etc.) and with goa there's really no excuse since you get the docs (swagger) for free...