Open pixlwave opened 5 days ago
Also related to #2262.
IMO those guidelines are odd, subjective and depend so much on context - you mention ID
but I doubt it would be difficult to find people who swear they use Url
or url
instead of URL
(and we work for a browser company :) For that and other reasons, I doubt uniffi would ever ship with a default acronym list. Further, things get a little more complicated when considering things like argument names. Would we end up with multiple lists, each for different contexts?
Which makes we wonder if a list even makes sense - it might not be clear exactly when this list is supposed to be consulted (and that may itself be subjective). So why not just have #1426 (and maybe companions for, say argument names etc)? It's one less level of indirection which might cause a small amount of duplication (eg, you'd need to list both getJSON
and setJSON
) but might be clearer and offers more control (ie, you get to say exactly what the identifier is called, not just control individual parts of it)
I doubt it would be difficult to find people who swear they use
Url
orurl
instead ofURL
I'm not sure I would agree here given skimming through the documentation for URL
and NSURL
(plus related types like URLComponents
, URLRequest
, URLSession
etc) should make it pretty obvious how unusual Url
would be for a Swift/Objective-C developer. (url
is perfectly acceptable based on the guidelines if it's at the start of a function/variable/argument e.g. urlString
).
For that and other reasons, I doubt uniffi would ever ship with a default acronym list.
Agreed, this should be defined by each project.
Further, things get a little more complicated when considering things like argument names. Would we end up with multiple lists, each for different contexts?
I don't think so, the conventions are applied everywhere e.g. loadSimulatedRequest(_:responseHTML:)
. I've added arguments to the initial comment as I see they were missing.
Which makes we wonder if a list even makes sense - it might not be clear exactly when this list is supposed to be consulted (and that may itself be subjective). So why not just have #1426 (and maybe companions for, say argument names etc)? It's one less level of indirection which might cause a small amount of duplication (eg, you'd need to list both
getJSON
andsetJSON
) but might be clearer and offers more control (ie, you get to say exactly what the identifier is called, not just control individual parts of it)
Semi-related to #1426, it would be great if UniFFI could generate Swift function/variable/argument/type names that conform to the “Follow case conventions” point in the Swift API Design Guidelines:
A couple of examples:
avatar_url
avatarUrl
avatarURL
raw_json_string
rawJsonString
rawJSONString
Some obvious thoughts that came out of an initial conversation:
uniffi.toml
as whilst some conversions likeURL
andJSON
aren't debatable, other such asID
may raise discussion as to whether or not they count (and this clearly isn't UniFFI's problem to deal with).