Hello together!

Now that the cycle problem was solved (I don't know whether it works, because I'm still trying to get a test working ^^), I've encountered the next problem. The android.widget.TextView class has a method setText that takes a CharSequence which is implemented by java.lang.String. As I've read in the wiki UnicodeString is mapped to that type. But the following code pieces don't compile (tv is the TextView of type AWTextView):

=== source begin ===

tv.setText('Hello World'); // Incompatible type for arg no. 1: Got
"Constant String", expected "LongInt"
var
   s: UnicodeString;
s := 'Hello World';
tv.setText(s); // Incompatible types: got "UnicodeString" expected
"JLCharSequence"
var
   s: UnicodeString;
   c: JLCharSequence;
s := 'Hello World';
c := s;
tv.setText(c); // Incompatible types: got "UnicodeString" expected
"JLCharSequence"
// the following works though
var
   s: JLString;
s := 'Hello World';
tv.setText(s);

=== source end ===

Can it be that the compiler doesn't check for the interfaces implemented by the mapped string type?

Regards,
Sven

Sven Barth wrote

Now that the cycle problem was solved (I don't know whether it works, because I'm still trying to get a test working ^^), I've encountered the next problem. The android.widget.TextView class has a method setText that takes a CharSequence which is implemented by java.lang.String. As I've read in the wiki UnicodeString is mapped to that type. But the following code pieces don't compile (tv is the TextView of type AWTextView):

The fact that something is implemented by something else does not mean that the semantics are identical. E.g. a "var s: set of TSomeEnum" is implemented via java.util.EnumSet, but that does not mean that you can pass such a set to any method expecting a java.util.EnumSet. Similarly, you cannot use "include()" with a java.lang.EnumSet class instance. One is a Pascal set type, the other is a Java class type and both have their own behaviour. It is however possible to typecast one to the other via JLEnumSet(@enumsetvar) and PEnumSetType(enumsetinstance)^.

Now, because strings are so common there's an exception in that unicodestrings will be implicitly typecasted to java.lang.String and vice versa (and in the svn version of the compiler, ansistrings and shortstrings will also be automatically converted to and from java.lang.String without typecasts). Automatic typecasting from unicodestring to java.lang.CharSequence could be added, but then it should also be added to java.lang.Object and then you very can get "cannot choose which overloaded method to call" situations, so I'm not sure whether this is a good idea.

Jonas

Ok, thank you for the explanation of the behavior.

Would adding an operator overload for implicit cast solve the problem? I'm not talking about adding it to System or JDK15, but maybe a seperate unit...

Regards,
Sven

Sven Barth wrote

Would adding an operator overload for implicit cast solve the problem? I'm not talking about adding it to System or JDK15, but maybe a seperate unit...

I don't think that is not possible. You can at least not overload the assignment operator for types that can be explicitly typecasted to each other (which is the case for unicodestring and JLCharSequence).

Jonas

-not

Jonas