remove InternalMap and Maps from metamodel APIs #404

Closed
gavinking opened this Issue Jan 31, 2014 · 16 comments

Projects

None yet

4 participants

@gavinking
Ceylon member

In order to slim down the language module, and reduce the amount of Java code we have to maintain, I propose that we:

  1. remove InternalMap, and
  2. change the APIs of OpenClassOrInterfaceType and Generic to not use Maps.
@gavinking
Ceylon member

Note: an alternative proposal would be to add official native implementations of (immutable) Map and Set to the language module, the way we have a couple of native implementations of List. I'm not especially keen on this, but it's worth considering, I suppose.

@quintesse
Ceylon member

I've always thought that having some implementation for data structures as basic as List, Set and Map in the language module would be an advantage. It just just makes the base language module so much more powerful. Then if you want mutability or certain performance properties or special behaviours you go to the collections module.

@tombentley
Ceylon member
  1. change the APIs of OpenClassOrInterfaceType and Generic to not use Maps.

What would they use instead?

@gavinking
Ceylon member

What would they use instead?

Well, they could use Correspondence and List, for example.

@tombentley
Ceylon member

OK, but then we're going to need an internal implementation of Correspondence somewhere. So doesn't this issue amount to replacing InternalMap with an InternalCorrespondence?

Are you proposing that InternalCorrespondence iterates a List to find the item for a given key?

@gavinking
Ceylon member

Well Correspondence is tiny, so sending its implementation across a wire would not cost much.

Are you proposing that InternalCorrespondence iterates a List to find the item for a given key?

Well, it could do that, or it could be implemented in java/js, which makes most sense, since the classes that use it are in java/js.

Anyway, that's not the only possibility. We could just have those methods return a {Key->Item*}. It's very trivial to turn such an iterable into a Map.

@gavinking
Ceylon member

I've always thought that having some implementation for data structures as basic as List, Set and Map in the language module would be an advantage.

OK, but it makes the language module fatter. I'm trying to figure out how we can trim some of the fat...

@quintesse
Ceylon member

I'm trying to figure out how we can trim some of the fat...

Understood. But it seems that in some cases we're just making our lives harder. The example with the API for OpenClassOrInterfaceType and returning a {Key->Item*} that by itself is not very useful means that to work with that API people are going to have to import the collections module.
Also to me it seems List, Set and Map are among the basic building blocks of any application, so I'd see them as the meat instead of the fat :)

@tombentley
Ceylon member

@gavinking are you concerned about the size of the language module mainly for JS or for both backends?

@quintesse
Ceylon member

I'm guessing neither, I'm guessing he's concerned with the "footprint" of the API itself.

@gavinking
Ceylon member

are you concerned about the size of the language module mainly for JS or for both backends?

For both backends (Android!) but of course especially for the JS backend.

Of course, the biggest optimization we need to make here is to somehow split out the metamodel into its own module or something. But that's a separate issue.

@gavinking
Ceylon member

I'm guessing he's concerned with the "footprint" of the API itself.

Well that too, but not primarily that.

@gavinking
Ceylon member

By the way, there's also a philosophical/aesthetic thing: Array is nasty and magical because it's not defined within the language or language specification. The same is true for ArraySequence and SequenceBuilder right now, but that will change when we reimplement them in Ceylon.

Now, I can live with Array since it's essential for performance on the JVM. But I don't want to unnecessarily grow the list of things that are like Array.

@gavinking
Ceylon member

By the way, there's also a philosophical/aesthetic thing

And this concern is not even purely aesthetic: Ceylon programmers are going to be stepping through Ceylon code, and then suddenly find themselves inside java.util.HashMap. That's not very nice.

In principle, of course, Ceylon doesn't need any natively-defined types. String, Integer, Float, and Array could all, in principle, be written in Ceylon. Sadly, performance would suck ass.

@FroMage
Ceylon member

This is a pretty bad change, as we talked of making more metamodel types implement Correspondence (or Map?), like for instance Module would be Correspondence<String,Package>.

@gavinking
Ceylon member

Closing, we're not going to make this change b/c it's no longer really going to simplify or shrink the language module much. An implementation of Correspondence would not be much smaller.

@gavinking gavinking closed this Jul 30, 2014
@gavinking gavinking self-assigned this Jul 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment