I'm considering a union type mechanism which would be reified as a type argument, using no wrapper objects
The same is true with my model. I see you have an issue with the "extra pass", right? It's in fact a "micro-pass", it will be very fast.
Another point of contention might be: retrofitting the String's RTO with an extra "implements Encodable" (that is, adding a reference to Encodable to the list of interfaces implemented by a String). That's what you are referring to when saying "String KNOWS that it implements Encodable". But it's not the only way to implement the feature. Let's say: String doesn't know that. but someone knows it in runtime, and when we invoke myObjectThatIsAStringDowncastToObject is Encodable, this someone handles it. But my model doesn't include the infinite switch!
This "someone" can compute `myObject is Encodable" by a hashtable lookup, in O(1). But this hashtable is precomputed 1. That's why we need an extra "micro-pass": to populate said hashmap statically. Please think about it. I feel that there's some misunderstanding either on your part or on mine, or maybe both, but I don't know how to pinpoint it.
Suppose the problem of detecting whether type is Encodable is solvable - maybe we have an oracle or something.
In your earlier posts, you mentioned "a can of worms" associated with union types. Can you give an example of one such worm?
Originally posted by @ghost in dart-lang/language#2727 (comment)
The same is true with my model. I see you have an issue with the "extra pass", right? It's in fact a "micro-pass", it will be very fast.
Another point of contention might be: retrofitting the String's RTO with an extra "implements Encodable" (that is, adding a reference to Encodable to the list of interfaces implemented by a String). That's what you are referring to when saying "String KNOWS that it implements Encodable". But it's not the only way to implement the feature. Let's say: String doesn't know that. but someone knows it in runtime, and when we invoke
myObjectThatIsAStringDowncastToObject is Encodable, this someone handles it. But my model doesn't include the infinite switch!This "someone" can compute `myObject is Encodable" by a hashtable lookup, in O(1). But this hashtable is precomputed 1. That's why we need an extra "micro-pass": to populate said hashmap statically. Please think about it. I feel that there's some misunderstanding either on your part or on mine, or maybe both, but I don't know how to pinpoint it.
Suppose the problem of detecting whether type is Encodable is solvable - maybe we have an oracle or something.
In your earlier posts, you mentioned "a can of worms" associated with union types. Can you give an example of one such worm?
Originally posted by @ghost in dart-lang/language#2727 (comment)
Footnotes
the hashtable in question is rather a hashset: it contains the runtime types that conform to Encodable. E.g. it contains
String,List<List<int>>etc. We can fully precompute this table because we know statically thatList<List<int>is indeed used by a program somewhere, but, say,List<List<List<anything>is not. So the size of the table is finite, and in fact rather small.Maybe you have a counterargument that shows that precomputing such a hashset is impossible? Even then, it's not the end of the story - we can discuss it further: the existence of specially constructed edge cases never occurring in practice is not a show-stopper. ↩