support option in abstract type (part 2)

[bobzhang]

No description provided.

[chenglou]

For those following this, see #2663

I have a few comments:

• What does the composition of [@@bs.deriving abstract] and [@@bs.deriving {jsConverter = newType}] look like?
• The bikesheddy point is whether to generate setHeight or heightSet. I understand the name mangling point but I think we should go over this
• Is it possible to go from a creation function to a record type instead?

[bobzhang]

Is it possible to go from a creation function to a record type instead?

No, the whole point is that the type is abstract type, so you can write portable code

What does the composition of [@@bs.deriving abstract] and [@@bs.deriving {jsConverter = newType}] look like?

The semantics is slightly different, in jsConverter, the type could be abstracted, but it does not have to be. In deriving abstract, it has to be an abstract type

[bobzhang]

let's move the discussion into #2614, the PR will be split into several parts

[chenglou]

No, the whole point is that the type is abstract type, so you can write portable code

Right. What about creation function that generates the abstract type? The main reason is that it circumvents some bs.optional or bs.default that'd otherwise be needed

[bobzhang]

What about creation function that generates the abstract type

it will generate it

[chenglou]

Yes, but I mean annotating a creation function, rather than declare a record type with potential [@bs.default] and [@bs.optional] annotations