You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When it comes to larger APIs, for example, the Google Classroom API, which I work with very often at glassroom, using Papyrus would result in a lot of messy top-level APIs.
How glassroom currently solves this is to declare all the protocols as enums, and all the functionality goes into extensions of those enums as static functions. This means that the definitions look like this:
// Definitions of all the APIs. They're implemented in other files.publicenum GlassRoomAPI {publicenum GRCourses:GlassRoomAPIProtocol{publicenumGRAliases:GlassRoomAPIProtocol{}publicenumGRAnnouncements:GlassRoomAPIProtocol{}publicenumGRCourseWork:GlassRoomAPIProtocol{publicenumGRStudentSubmissions:GlassRoomAPIProtocol{}}/* etc */
and calling functions looks more like this:
GlassRoomAPI.GRCourses.GRCourseWork.list(/* parameters here */){ result in/*completion here*/}
However, since Papyrus uses protocols for the definitions and the resultant APIs are autogenerated, such organisation cannot be achieved.
@APIprotocol GRCourses {/*methods here*/@APIprotocolGRAliases{// does not compile, as you cannot define other objects within a protocol/*methods here*/}}
Suggested solution:
My suggestion is to have an option in @API and @Mock to extend a struct with the new functionality, instead of generating a whole new struct. This would allow for organisation by defining all the structs in a neat manner.
// empty implementationsstructGRCourses{structGRAliases{}}@API(in:GRCourses.self)protocolGRCoursesProtocol{/* methods here */}@API(in:GRAliases.self)protocolGRAliasesProtocol{/* methods here */}/* // autogenerated:extension GRCourses { /* implementations here */}extension GRAliases { /* implementations here */}*/
Great idea! I 100% agree it would be great to be able to better organize large API groups. Unfortunately macros are relatively nascent and so there are a few limitations:
At the moment, macros aren't allowed to generate extensions. There's some movement towards removing this limitation but until then anything involving extensions on existing types isn't possible. Hopefully that will land soon, but before then I believe generating a new top-level type is the only viable solution.
Ideally, I think it would be great to completely hide the implementor of the protocol. This way there wouldn't be a bunch of concrete API types floating around and calling the API would look something like this:
Macros generating extensions would also unlock the in parameter as you recommended to further allow organization via nesting inside enums, structs, etc. Once it's available I think that would be a great addition.
Unfortunately there's still no way for macros to extend types that they aren't annotating - but I think with this answer you should be able to get more organized outputs as long as there's a consistent suffix.
Issue:
When it comes to larger APIs, for example, the Google Classroom API, which I work with very often at glassroom, using Papyrus would result in a lot of messy top-level APIs.
How glassroom currently solves this is to declare all the protocols as enums, and all the functionality goes into extensions of those enums as static functions. This means that the definitions look like this:
and calling functions looks more like this:
However, since Papyrus uses protocols for the definitions and the resultant APIs are autogenerated, such organisation cannot be achieved.
Suggested solution:
My suggestion is to have an option in
@API
and@Mock
to extend a struct with the new functionality, instead of generating a whole new struct. This would allow for organisation by defining all the structs in a neat manner.And you would call them this way:
The text was updated successfully, but these errors were encountered: