string-field and http

[amitu]

-- record ftd.string-field:
caption name:
string value: *$ftd.empty
optional string error:

-- void submit(username, org_slug):
ftd.string-field username:
ftd.string-field org_slug:

;; send can be left empty if we have nothing to send
ftd.post("/ft2/myself/create-org/").send(username, org_slug)

[amitu]

What about fields of other types? Should we create ftd.integer-field etc as well? What about user defined types?

Since this is ftd.string-field etc is going to be consumed by ftd.submit_form() method, should we implement "structural typing", and assume any record with the three fields will do. When we change type only the type of value is going to change.

This is a good opportunity for us to think about generics too. Do we want generic in fastn? We have def considered result and option types, even the remote type, so generic or structural typing?

We can do structural types only at our special function level, so for user code they deal with their own records, only when they call the ftd.submit_form() we verify that types have appropriate fields. We can do that in compiler as well eventually so this does not remain a runtime check. But what if someone wants to create a wrapper over ftd.submit_form(), how do they declare the types of args? Each arg is of different type. Even with generic support it would be ergonomically painful, someone will have to create an enum with a variant for all the type one wants to support, so it would be not a great helper. Or we do some sort of into-json trait along with generic, and store a vec containing trait objects implementing into-json or something. We can argue all fastn types are automatically into-json, but as a pattern this then only works for into-json, and does not answer our question of should we support structural typing or not.