Issue with Java Strings as type arguments #488
Comments
[@FroMage] Same issue with j.l.Object used as type param |
[@FroMage] Though, for Can anyone remind me why we erase to |
[@gavinking] |
[@FroMage] Ah true. But the opposite is true… How can we fix this sort of problem? |
[@FroMage] I've simply no idea how to fix this, short of giving up and stopping to optimise I mean, I see why we're sometimes erasing to Tako says that we could produce code that calls helper methods rather than always box/unbox java strings, so we'd keep only java strings, but that doesn't help us if we're still using ceylon strings as type parameters, since that will always require boxing, and doesn't work with the pretended equivalence with java strings (different type parameter constraints) For primitives this problem doesn't exist, but we decided to not treat Tako says that we're erasing to java strings because the JVM optimises them and we'd need to convert ceylon strings to java strings anyways for most APIs, which will not be true anymore once we have Pure Ceylon libs. I think we should just stop treating |
[@quintesse] After discussing this some more with @FroMage we seem to have some serious problems with Java interop here, right? |
[@quintesse] The only thing we've been able to think of thus far is to stop treating |
[@gavinking] So, after some playing to see what the interop code actually does, it appears that there is no actual hole in the type system, since the following code all compiles and runs:
The compiler doesn't treat So it seems that:
Now, lets say we discover that
Now, of course, the nice thing about this is it also neatly resolves the problem of not being able to iterate Yes, I'm ignoring the mutability issue for now, and there might be some other problems here that I'm missing. |
I'm still not convinced that this is the right thing, and we might need to revisit it. Certainly we can't have model loader do to
There's certainly a good argument for that. I'm conflicted.
Well, we don't know the details of this optimization or even if it really exists. |
...
I mean, it's an option, and it would not be the end of the world, but hell, all those calls to |
[@FroMage]
No it doesn't, it (confusingly) reports that: The problem I see with trying to autobox ceylon and java strings is that it doesn't always work: import java.lang { Str=String }
import java.util { List, ArrayList }
List<Str> slist = ArrayList<Str>();
slist.add(Str("hello"));
slist.add(Str("goodbye"));
for (i in 0..slist.size()-1) {
Str s = slist.get(i);
print(s);
} It's not at all obvious to the users why the following autoboxing doesn't work: import java.lang { Str=String }
import java.util { List, ArrayList }
List<Str> slist = ArrayList<Str>();
slist.add("hello"); // autoboxing
for (i in 0..slist.size()-1) {
String s = slist.get(i); // autoboxing
print(s);
} Yet it doesn't. When we do autoboxing of java strings to/from ceylon strings we give the impression that the two are interchangeable, which is indeed the case for Java's autoboxing (except for null), but then users will notice that there are some situations where autoboxing doesn't work and they will point at it and say: "look, this is inconsistent". |
OK, I was just going by the initial description of the issue, which seems to say that:
If that's not the case (i.e. we in fact don't always assume that), then there is no "actual bug" here at all, just the observations that:
Again, I simply don't know the answer to 2. I'm inclined to think it might not be a really big issue. |
[@FroMage] You did fix one of the error messages, but there's another confusing one for this case: List<JString> jstringList = java.jstringList();
jstringList.add("foo"); (Where
|
[@gavinking] > You did fix one of the error messages, but there's another confusing one for this case: Right, there are a number of cases like this. But I've no idea how to detect them in general. I don't want to always use fully-qualified names in error messages. |
[@FroMage] 558111626f0ca3e5b7767c7d95ba0d2c5c0f868e and 775c582cd6fdded3656b3cda1dd0203b7fc7f4d8 were for this issue. Now fixed. |
[@FroMage] When using some Java code that returns a
java.util.List<java.lang.String>
we get a weird issue thatString
is not assignable toString
because we assume that when used as a type parameter,String
should be mapped toceylon.language.String
, which is just not always the case. We need to fix that.[Migrated from ceylon/ceylon-compiler#488]
[Closed at 2012-06-04 14:30:13]
The text was updated successfully, but these errors were encountered: