Open tjjfvi opened 1 year ago
@vjjft suggests scald
import { $func } from "x"
export const $api = $.field(
"a",
$.field(
"b",
$.field(
"c",
$func($.tuple(), $.str)
)
)
)
$func
) with scale-
/ aka. scale-func
?fn
instead of func
, but this isn't a strong opinion.I'd personally prefer
fn
instead offunc
, but this isn't a strong opinion.
Agreed.
is an object definition desirable? What other schemes might we consider? In an offline convo, you mentioned deeply-nested fns.
Yes, $fn
would be general such that you could nest fields like that, return functions from functions, etc.
What do we want as a convention for scale lib naming? Do we want to simply prefix the subject codec (in this case a
$func
) withscale-
/ aka.scale-func
?
scale-foo
as a general convention seems reasonable, but given that this library isn't simply a collection of codecs (but rather an api building off of scale), I think a name not following this convention makes sense. I'm fond of scald
, personally.
what connection types should be supported out-of-the-box?
Web sockets and workers, at minimum. Ideally we should also make it as easy as possible to use with custom connections.
I'm fond of scald, personally.
When I first read the suggestion of scald
, it sounded a bit aggressive (no one wants to be scalded). But I suppose JS tools have a sorted past of heat-related names #blazingly. Another contender: scall
.
EDIT
Scall is defined as "a scurf or scabby disorder," so that's a no.
Name TBD –
srpc
?scalar
?