-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding arbitrary properties on schemafields #47
Conversation
return prop, true | ||
} | ||
} | ||
return "", false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be return nil, false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, good catch
I'm a bit concerned about consistency of I'm not sure why we implemented the I really don't want to make breaking changes so I'll rather leave it a bit inconsistent if you really need the Thanks! |
I get that, I was thinking the same thing. Unfortunately I need an array for one of the properties and I'd like to avoid doing something like joining them as a string and splitting on some delimiter. I can change the name of the function Prop to ArbitraryProp to draw a distinction. If thats the case, it may make sense to add that ArbitraryProp function to the other Schema structs and add it to the interface to allow the same functionality. |
I like your approach. This way we could remove Prop in future releases (but not right now) because Prop and ArbitraryProp are nearly identical. I think it's ok to have them both for now not to break anyone and preserve consistency. Let's go for it. |
All the |
Ok I've had a night to think about that :) In my opinion we have two options:
The second one looks a bit ugly and workaround-ish to me. I'll talk to other collaborators today and let you know if they support this approach as well. |
@barnjamin ok we agreed on the first approach, I'll create a release right now and then we could accept that breaking change. Thanks! |
@serejja could you use semantic versioning for breaking changes? This way you also have a path down the road for using the gopkg.in service I would also propose that if you're thinking of going down the road, break everything you plan on breaking soon, and then get a stable API going. |
No description provided.