09:55 <FromGitter> <moe:busyloop.net> is there any way to get at the return type that crystal magically determines for a method during compilation when none is explicitly specified?

09:55 <FromGitter> <moe:busyloop.net> https://carc.in/#/r/czt0

09:55 <FromGitter> <moe:busyloop.net> i assume probably not :/

10:41 <Guest38> Hey folks. If someone has a wikipedia account they could modify the page for Rust to mention Crystal as well. Seems pretty fitting among the listed languages in this sentence: "... commented on Rust's chances of becoming a competitor to C++ and to the other up-and-coming languages D, Go, and Nim (then Nimrod)"

10:55 <jhass[m]> You don't need an account to edit wikipedia, https://en.wikipedia.org/w/index.php?title=Rust_(programming_language)&action=edit

13:04 <FromGitter> <Blacksmoke16> @moe:busyloop.net no, because it could probably change? If possible this is why its just easier to add a return type

13:42 <FromGitter> <HertzDevil> the def is separately instantiated for each set of argument types, so there isn't "an" inferred return type of the def

15:09 <FromGitter> <moe:busyloop.net> hmm makes sense. guess what i'd like is a way to inspect all the def's that are generated. ⏎ but i see why that isn't exactly feasible.

15:15 <FromGitter> <moe:busyloop.net> yeh, sometimes i'd just like to act on what the user actually returned w/o forcing them to explicitly declare it. in this case for generating the `responses` portion of swagger-docs based on what types an endpoint actually returns. forcing the user to be explicit can be annoying when it comes to nested and nilable types.

15:17 <FromGitter> <Blacksmoke16> in this case shouldnt an endpoint return essentially the same thing everytime?

15:18 <FromGitter> <Blacksmoke16> not like it could return a big union of things really?

15:24 <FromGitter> <moe:busyloop.net> well, in principle, yes. hmm, maybe i'm indeed making it too complicated. ⏎ i'll see how far i can get by forcing that def to be explicit.

15:27 <FromGitter> <Blacksmoke16> only exception is error responses, but if you raise them, they technically wouldnt be returned and you could handle that elsewhere

15:32 <FromGitter> <moe:busyloop.net> yeh, those i already got covered. in the renderer for an exception type you can declare whether it should automatically be injected into the swagger docs for all endpoints (useful for all the base-exceptions that can happen on any endpoint). and endpoints can declare the additional exceptions that they may throw (no way to discover them otherwise).

15:33 <FromGitter> <moe:busyloop.net> actually happy with how that part looks. thought that would be the harder one, but turns out the return types is actually more tricky as it fans out into return-type(s) -> renderer -> content-types.

15:35 <FromGitter> <moe:busyloop.net> getting that stuff to work at runtime was surprisingly easy (yay for crystal!). now discovering it *before* runtime to build those swagger docs. uff.

15:41 <FromGitter> <Blacksmoke16> i just made them required in athena, for diff reasons but the point is the same

15:42 <FromGitter> <Blacksmoke16> not *super* familiar with swagger, but i know they have a concept of models of which you'd use to represent the response yea? then from there is prob a way to show how they are rendered given various content types?

15:45 <FromGitter> <Blacksmoke16> i.e. the core type of the response doesnt change, just its representation

15:45 <FromGitter> <Blacksmoke16> serialized representation that is

15:53 <FromGitter> <moe:busyloop.net> ha, yea, you're pointing right at the hard part. ⏎ at first i had the models generate their swagger-schema. ⏎ ⏎ but then i realized, endpoints often only return a partial view of a model ⏎ (i.e. you don't want to include the password-field with users and don't want ... [https://gitter.im/crystal-lang/crystal?at=624c66049a09ab24f3dad3b8]

15:55 <FromGitter> <Blacksmoke16> prob a good idea to have a separate object used to represent payload/responses versus assuming that is going to match the DB model 1:1

15:55 <FromGitter> <Blacksmoke16> https://en.wikipedia.org/wiki/Data_transfer_object

15:56 <FromGitter> <Blacksmoke16> crystal stdlib and some shards have the ability to like exclude serializing the password on serialize but accept it on deserialize, but DTO would be a more robust way to go about that imo

15:56 <FromGitter> <Blacksmoke16> esp for more complex models so that the structure of the request doesnt need to be tightly coupled to the db schema

15:59 <FromGitter> <moe:busyloop.net> yea, rails has ActiveModelSerializer for this. guess i may just want too much ("just return whatever you want, we'll render & auto-doc it"). ⏎ works fine up to the point of auto-doc'ing & validating the input parameters. but the return value, that's really a tough cookie.

16:01 <FromGitter> <Blacksmoke16> ultimately you'd need to define what those validations are *somewhere*

16:03 <FromGitter> <Blacksmoke16> using a DTO for that would get you that + the structure of the request

16:04 <FromGitter> <Blacksmoke16> and have another for the response that describes the response

16:04 <FromGitter> <moe:busyloop.net> yup. i'll dig more into it in the coming days.

16:05 <FromGitter> <Blacksmoke16> could use the validation component for that ;)

16:05 <FromGitter> <Blacksmoke16> but sounds good 👍