-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch property accessors to records-as-objects #2
Comments
We could perhaps offer a |
If this happens we'll need The pain of documenting this would be immense; I no longer think it's worth considering for 1.0. |
Just occurred to me, what about doing the reverse as a potentially easier migration? e.g. type t = Dom.domRect;
type internal_t =
pri {
top: float,
bottom: float,
left: float,
right: float,
height: float,
width: float,
x: float,
y: float,
}
external unwrap: t => internal_t = "%identity"
[@bs.new] external make : (~x: float, ~y: float, ~width: float, ~height: float) => t = "DOMRect"; /* experimental */
[@bs.get] external top : t => float = "";
[@bs.get] external bottom : t => float = "";
[@bs.get] external left : t => float = "";
[@bs.get] external right : t => float = "";
[@bs.get] external height : t => float = "";
[@bs.get] external width : t => float = "";
[@bs.get] external x : t => float = "";
[@bs.get] external y : t => float = ""; |
Yeah making custom types not the default reduces the impact, although it does reduce the usability a little, that's an interesting thought 🤔 |
Because of the record improvements in ReScript 11 doing this would also allow up-casting from |
That is certainly a major advantage - but it depends on breaking away from the compiler types. It's such a big change, the compatibility issues it would cause mean I'd want to get input from the compiler developers before I invest time in it. |
Every property accessor in the entire project is an external. When bs-webapi was created that was the only way to do it. Since then records are compiled to objects so we can use (private) record types to represent the properties.
For example, DomRect:
Can now be implemented as:
This is still up for debate, because by not using the ReScript-provided abstract types like
Dom.domRect
this will break compatibility with other DOM-related libraries. The improved ease of use is worth it in property-heavy types likeDOMRect
, but perhaps it should be used sparingly.The text was updated successfully, but these errors were encountered: