Skip to content

api: Document, and sweep for, our practice of making constructor arguments explicit #367

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

Merged
merged 8 commits into from
Nov 4, 2023

Conversation

gnprice
Copy link
Member

@gnprice gnprice commented Nov 4, 2023

This came up in a code review at #361 (comment) , and it'd be good to have written down in a more accessible place. Add this to the README (which for now doubles as our proto-style-guide):

In our API types, constructors should generally avoid default values for their parameters, even null. This means writing e.g. required this.foo rather than just this.foo, even when foo is nullable. This is because it's common in the Zulip API for a null or missing value to be quite salient in meaning, and not a boring value appropriate for a default, so that it's best to ensure callers make an explicit choice. If passing explicit values in tests is cumbersome, a factory function in test/example_data.dart is an appropriate way to share defaults.

Then there are some existing parts of the API bindings — particularly the parts written in the very first week or two of the prototype, before I thought through this pattern — that don't follow this. So sweep through fixing those, and leave explanatory comments on the only two places left as exceptions to the pattern.

…icit

This came up in a code review here:
  zulip#361 (comment)

and it'd be good to have written down in a more accessible place.

There are some existing parts of the API bindings -- particularly the
parts written in the very first week or two of the prototype, before I
thought through this pattern -- that don't follow this.  I'll fix
those up next.
This appears to have been done in commit zulip/zulip@bd2545b0d.
It's fine for it to have gone away -- the new API is better,
and we weren't using this field -- but there's no notice of the
change in the API changelog or the endpoint's own API docs.
That shouldn't happen.  I'll follow up.

Anyway, now that I've sleuthed out the mystery of what happened,
remove this from our bindings to match.
This reflects the real semantics, and will simplify things if we
ever actually use this field.

Also clarify what the todo-server comment refers to.
This completes the sweep for the point of style we added
to the README a few commits ago.
@chrisbobbe chrisbobbe merged commit 89ead46 into zulip:main Nov 4, 2023
@chrisbobbe
Copy link
Collaborator

Thanks, LGTM! Merged.

@gnprice gnprice deleted the pr-api-explicit branch November 4, 2023 02:33
@gnprice
Copy link
Member Author

gnprice commented Nov 4, 2023

api: Cut SendMessageResult.deliverAt, quietly deleted from API

Followed up on this in #api design here:
https://chat.zulip.org/#narrow/stream/378-api-design/topic/scheduled.20messages/near/1675568

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants