Skip to content
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

Future proof matching of native types #1688

Closed
jacob314 opened this issue Feb 15, 2012 · 11 comments
Closed

Future proof matching of native types #1688

jacob314 opened this issue Feb 15, 2012 · 11 comments
Labels
closed-obsolete Closed as the reported issue is no longer relevant P3 A lower priority bug or feature request type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) web-dart2js

Comments

@jacob314
Copy link
Member

If in the future a web browser introduces a new type (for example this past year chrome introduced HTMLSpanElement), frog code that doesn't know about the new type will fail catastrophically rather than gracefully. Ideally, all members from parent types of the new type should still resolve. For example, HTMLSpanElement inherits from HTMLElement so its reasonable to expect that all HTMLElement methods should still be accessible on HTMLSpanElement even if the compiler doesn't know about HTMLSpanElement specifically.
This will become more of an issue if the DOM ever supports user definable subtypes of HTMLElement.

@anders-sandholm
Copy link
Contributor

Added Triaged label.

@anders-sandholm
Copy link
Contributor

Removed Area-Frog label.
Added Area-Dart2JS, FromAreaFrog labels.

@kasperl
Copy link

kasperl commented Jun 12, 2012

Smells like a DOM issue. Is it?


Removed Area-Dart2JS, FromAreaFrog labels.
Added Area-DOM label.
Changed the title to: "Future proof matching of native types".

@vsmenon
Copy link
Member

vsmenon commented Jun 22, 2012

Added this to the Later milestone.

@iposva-google
Copy link
Contributor

Removed Area-DOM label.
Added Area-HTML label.

@vsmenon
Copy link
Member

vsmenon commented Aug 17, 2012

Removed the owner.

@kevmoo
Copy link
Member

kevmoo commented Apr 7, 2014

Removed Area-HTML label.
Added Area-Library, Library-Html labels.

@kasperl
Copy link

kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl
Copy link

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@efortuna
Copy link
Contributor

efortuna commented Aug 8, 2014

Moving to area-Dart2js as this seems more like an issue with how we're generating the JavaScript. This isn't an issue on the dartium side since we're generating all of our types right from the IDL.


Removed Area-Library, Library-Html labels.
Added Area-Dart2JS label.

@efortuna
Copy link
Contributor

efortuna commented Aug 8, 2014

Alternatively we might just want to close this out as a "duplicate", as it deals with the same issues as https://code.google.com/p/dart/issues/detail?id=13285

@jacob314 jacob314 added Type-Defect P3 A lower priority bug or feature request web-dart2js labels Aug 8, 2014
@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed triaged labels Feb 29, 2016
@matanlurey matanlurey added the closed-obsolete Closed as the reported issue is no longer relevant label Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-obsolete Closed as the reported issue is no longer relevant P3 A lower priority bug or feature request type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) web-dart2js
Projects
None yet
Development

No branches or pull requests

8 participants