Closed jmesserly closed 9 years ago
The "coreimpl" is not supposed to be a public interface, but rather (varying) implementations of core interfaces.
(Originally "coreimpl" was not accessible to user programs at all. While some similarity issues can be improved, the implementations will never match.)
The user programs should program to the interfaces of "core" library not to "coreimpl". If there are "coreimpl" interfaces that seems to belong to core library, then we should file individual issues.
Whoa. If that's true I don't see why coreimpl can be imported by user code at all.
Maybe the issue then is why so much useful, not implementation specific stuff is in coreimpl instead of corelib, like concrete collection implementations (hash map, splay tree, etc): http://dart.googlecode.com/svn/branches/bleeding_edge/dart/corelib/src/implementation/
Or useful things under {runtime|frog|compiler}/lib like: Collections, ByteBuffer, ImmutableArray/Map (what if I want to create one from values that aren't compile time const?) the actual List implementations, etc...
This bug doesn't apply anymore. Coreimpl has been removed in experimental/lib_v2.
Added AssumedStale label.
Agreed. This does not apply anymore.
There's still an open issue about extending List's default implementation, which is tracked in this bug: http://code.google.com/p/dart/issues/detail?id=2600
coreimpl is largely provided by the implementations (dartc, vm, frog), there's no check that they are all exposing the same coreimpl interface. And right now it doesn't look very consistent between the three. Just to take List as an example: VM has ObjectArray/GrowableObject array, DartC has ListImplementation, and Frog has ListFactory (expect a fix soon to call it ListImplementation).
One idea here: define all the interfaces in coreimpl, and implementation specific classes should be marked with a leading underscore so users don't depend on them.