[fpc-devel] Re: JVM: class of XYZ => java.lang.Class

[Sven Barth]

On 25.12.2011 22:26, Sven Barth wrote:
> On 25.12.2011 22:11, Jonas Maebe wrote:
>>
>> On 25 Dec 2011, at 22:06, Sven Barth wrote:
>>
>>> On 25.12.2011 20:53, Jonas Maebe wrote:
>>>>
>>>> On 25 Dec 2011, at 18:23, Sven Barth wrote:
>>>>
>>>>> Ok, I could simply solve this by doing a typecast
>>>>> "JLClass(TTrainTypeActivity)",
>>>>
>>>> That's indeed the proper way.
>>>
>>> Ok, if you say so. Thanks.
>>
>> The main problem is that the more magic conversions are added to the
>> compiler, the harder things become to maintain (both for the JVM
>> target and for other targets).
>
> I understand that, but from a user point of view it's rather confusing
> (Strings are another prominent example here). It might be a good idea if
> someone (not necessarily you) writes down these little caveats so that
> others don't need to hunt down these problems again.

To explain what I mean with "Strings" here:

I have code like this in my application (all units $H+ and $modeswitch 
unicodestrings):

var
   s: String;
begin
   s := SomeJLStringReturningFunction;
   s := 'SomeConstantString' + s;
   DoSomethingWithJLString(s);
end;

because this code:

var
   s: String;
begin
   s := 'SomeConstantString' + SomeJLStringReturningFunction;
   DoSomethingWithJLString(s);
end;

and this one:

var
   s: JLString;
begin
   s := 'SomeConstantString' + SomeJLStringReturningFunction;
   DoSomethingWithJLString(s);
end;

do not compile (both complain about "operator not overloaded" at the 
concatenation).

Regards,
Sven