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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
