sigmundch

Mmm... if you trap the error, is that before or after a dialog is shown to the user? If it is before, what about reverting to use `:view` if `:edit`...

Hi @BlueRayi - thank you for reaching out and for providing great details! This may not be the answer you are looking for, but this is in great part by...

/cc @rakudrama in case there is anything else to add

Sorry, just catching up after being on PTO. > Is there a reason we want to encourage JS interop usage instead of fixing the APIs? Note that the web components...

Rocking the boat a bit here - I'd like to revisit our requirements from JSInterop and see if "extension/subclassing" is the right model here. Some alternatives to think about: *...

I do like that. and the export syntax is growing on me. I could even imagine using the show/hide as well: ```dart class A { ... export e show add,...

Thanks @eernstg for taking a look. Precisely, your thoughts here are very aligned with I'm suggesting. In [this comment][1] I raise a similar but more general question: are there other...

I think we are all in agreement :) - that's why I was asking for the notion of "conformance", so we can statically express that the `for-in` is well formed....

I'm very much aligned with @lrhn here. When I read `X implements Y`, I expect `(X x) => x is Y` to return `true`. If `X` is an extension structs/view,...

Note that only **instance** members cannot be renamed, so the rule would still be applicable to static top-level methods. I think it's OK to bypass the lint on JS-interop external...