Rename JSValueConstructible and JSValueConvertible

[MaxDesiatov]

I always forget which is which, maybe something like ConvertibleToJSValue and ConstructibleFromJSValue would be more explicit?

[j-f1]

The fork I based those implementations off of used JSValueEncodable and JSValueDecodable. I kept the existing names because they match existing type names (like CustomStringConvertible). Maybe JSValueConstructible could be renamed ExpressibleByJSValue to match ExpressibleByStringLiteral?

[MaxDesiatov]

I like ExpressibleByJSValue 👍

[kateinoigakukun]

I prefer ConstructibleFromJSValue because ExpressibleByXXX is mainly used for literal expressible types in stdlib.

They are examples of protocol naming uses in stdlib.

• XXXConvertible: Self -> Target
• XXXBrigable: Self -> Target & Target -> Self
• ExpressibleByXXX: Literal -> Self

[MaxDesiatov]

I also wanted to mention that Expressible is used mainly for literals. But then I recalled that Swift Argument Parser library from Apple folks has ExpressibleByArgument protocol, which is not strictly about literals. Either way, I don't have a strong opinion here about alternatives, I just find the status quo a bit confusing 😅

[kateinoigakukun]

I discussed this topic in the Japanese Swift community and I think ConstructibleFromJSValue and ConvertibleToJSValue are the best pair.

• JSValueConvertible/JSValueConstructible

This pair is really ambiguous about "input" and "output".

• JSValueEncodable/JSValueDecodable

It feels like Encode/Decode implies that member methods do some serialization. But our protocol does not serialize but just convert JS/Swift values.

• JSValueConvertible/ExpressibleByJSValue

From stdlib use cases, ExpressibleBy prefix implies that the protocol is related to literal.

• JSValueConvertible/ConstructibleFromJSValue

XxxConvertible is used to represent one-way transformation in stdlib, and data info may be lost while transformation.
If the transformation is intended to preserve data info, the protocol has explicit "Lossless" prefix. (e.g. LosslessStringConvertible)

• ConvertibleToJSValue/ConstructibleFromJSValue

It feels like this pair is the most explicit representation and is precise pair.

[j-f1]

Created #88. One last thing to consider: is JSValueCodable a good name? Should we rename it or maybe even delete it?

public typealias JSValueCodable = ConvertibleToJSValue & ConstructibleFromJSValue

[MaxDesiatov]

I just started preparing a PR like that myself, but you were first 😄

I'd suggest JSValueCompatible as a replacement for JSValueCodable.