Error: conflicting types for "Element"

[DartBot]

This issue was originally filed by [email protected]

---

What steps will reproduce the problem?

1. adding this line to dart/utils/dartdoc/interact.dart:
      var query = new Element.tag('input');

breaks the compilation of interact.dart

../../client/html/release/html.dart:11520:1: error: conflicting types for "Element"
interface Element extends Node /*, common.NodeSelector, common.ElementTraversal */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
../../frog/element.dart:9:1: error: conflicting types for "Element"
class Element implements Hashable {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What version of the product are you using? On what operating system?
bleeding_edge, revision 2883

Please provide any additional information below.
Problem started 29.12.2011 around noon.

[dgrove]

nice naming conflict :(

Assigning to frog, but this is a nasty example of the name collision issues that we've been seeing.

---

cc @munificent.
cc @jacob314.
cc @jmesserly.
cc @gbracha.
Added Area-Frog, Triaged labels.

[jmesserly]

IMO, the best fix would be to improve language prefixes so disambiguation is only needed for actual conflicts.

As a stopgap we could rename compiler types so they don't conflict with the DOM, but that seems strange, since the compiler is not usually running in the browser. And the DOM steals some good names like "Node" and "Element"

---

Removed Type-Defect label.
Added Type-Enhancement label.

[jmesserly]

Moved to enhancement because there is a workaround: use prefixes for either frog or the html lib.

[DartBot]

This comment was originally written by [email protected]

---

Workaround looks ok.

One problem: you will need to rewrite any files sourced into the current library to reflect the new prefix.

[anders-sandholm]

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

[kasperl]

Is this a DOM issue?

---

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

[jacob314]

This is not a DOM issue. The problem was just that the frog library and the DOM library both have classes named element. The DOM class named Element should stay named element. If you actually wanted to import both dart:html and a compiler containing a class named Element, the right solution is to prefix one of the two libraries ideally with a mechanism that allows only prefixing the actual conflicts.

[gbracha]

So, given import scoping changes and show:, hide: in the pipeline, I expect this will be simple to resolve (once those features are implemented):

#import ('dart:html');
#import('frogLib.dart', prefix: 'frog');

Or (f all you wantto worry about prefixing is frogLib.Element)

#import('frogLib.dart', hide: ['Element']);
#import('frogLib.dart', prefix: 'frog', show:["Element']);

[jmesserly]

Agreed. Closed as by design of language prefixing mechanism.

---

Added AsDesigned label.