Makes sense. This has been brought up before in the #webassembly channel.
Don't remember what the conclusion was. But please feel free to drop in and
throw some ideas around.
Demand for a proper DOM API has been growing. And I think auto-generating
from WebIDL files are a great way to get started.
On Friday, 28 December 2018 17:46:22 UTC+5:30, Chris FractalBach wrote:
>
> This is in the context of compiling Go to webassembly that will be used
> with javascript.
>
>
> *Currently:*
>
> We have`syscall/js` which has stuff like this:
> ```go
> js.Global().Get("document").Call("createElement", "div")
> ```
>
> What it could be:
> ```go
> js.document.createElement("div")
> ```
>
>
>
> *Why?*
>
> This would make writing stuff for webassembly WAY easier.
> Auto-generating it would allow it to update definitions whenever the
> standards
> are updated. Which would make it easier to maintain.
>
> Also, if there's going to be significant usage of
> Go -> webassembly -> web browser and javascript
> then having all the types and definitions auto-generated would save on tons
> of boilerplate abstractions that people will inevitably create for their
> own sanity.
>
> Advantages:
> - more natural to use
> - more readable
> - type safe
>
> Disadvantages:
> - less flexible
> - when the APIs are updated, it might result in loss of
> backwards-compatibility
>
>
>
>
> *How?*
>
> WebIDL --> Go source code
>
> - https://www.w3.org/TR/WebIDL/
> - https://heycam.github.io/webidl/
> - https://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html
>
>
>
>
> Technical reports published by the W3C that include programming language
>> interfaces have typically been described using the Object Management
>> Group’s Interface Definition Language (IDL) [OMGIDL]. The IDL provides a
>> means to describe these interfaces in a language independent manner.
>> Usually, additional language binding appendices are included in such
>> documents which detail how the interfaces described with the IDL correspond
>> to constructs in the given language.
>
> https://www.w3.org/TR/WebIDL/#introduction
>
>
>
>
>
> *A Possible Conversion:*
>
> *From WebIDL:*
> ```
> [Exposed=Window]
> interface Paint { };
>
>
> [Exposed=Window]
> interface SolidColor : Paint {
> attribute double red;
> attribute double green;
> attribute double blue;
> };
>
>
> [Exposed=Window]
> interface Pattern : Paint {
> attribute DOMString imageURL;
> };
>
>
> [Exposed=Window, Constructor]
> interface GraphicalWindow {
> readonly attribute unsigned long width;
> readonly attribute unsigned long height;
>
>
> attribute Paint currentPaint;
>
>
> void drawRectangle(double x, double y, double width, double height);
>
>
> void drawText(double x, double y, DOMString text);
> };
>
> ```
> Example From: https://heycam.github.io/webidl/
>
>
>
> *To Go:*
>
> This is probably not the best way to do it, but is an example of how it
> might look.
>
> type Paint struct {}
>
>
> type SolidColor struct {
> Red float64
> Green float64
> Blue float64
> }
>
>
> type GraphicalWindow struct {
> width uint32
> height uint32
> CurrentPaint Paint
> }
>
>
> func (gw *GraphicalWindow) drawRectangle(x, y, width, height float64) {
> // syscall
> }
>
>
> func (gw *GraphicalWindow) drawText(x, y float64, text string) {
> // syscall
> }
>
>
>
>
>
>
> I know there are some existing examples of Go bindings for DOM,
> but I don't think they are auto-generated from WebIDL,
> Which I imagine would be easier to maintain in the long-run.
>
>
>
>
> Anybody have thoughts on this?
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
