Weird issue w/String

Elements
,
1

[Running a private 2364 build from @mh)

Test project:
org.me.androidapplication.zip (42.8 KB)

This project is a basic Android application (from the Cooper/Android template) which includes a class library, which in turn includes a shared project.

This shared project contains a basic protocol and a class which implements it:

public protocol StringRepresentable {
    var stringValue: String { get }
}

public class SomeClass: StringRepresentable {
    var stringValue: String {
        return "Hello"
    }
}

The main application tries to use that class but doesn’t seem to recognize it as a String:

33
Capture d’écran, le 2019-01-25 Ă  10.26.33.png1536×320 38.9 KB

This is somewhat confusing to me as, when I click the String type in the shared project, it tells me it’s a RemObjects.Elements.System.String, mapped to java.lang.String:

54
Capture d’écran, le 2019-01-25 Ă  10.27.54.png1518×194 21.5 KB

Cmd-clicking on String brings these definitions, which include the ‘missing’ isEmpty() function:

07
Capture d’écran, le 2019-01-25 Ă  10.29.07.png1516×746 147 KB

What’s happening here?

2

Are you using Elements RTL? if yes, your strings will be Elements RTL Strings (mapped to the Java string under the hood), which hides the Java-specific APIs. if not, this should work.

3

Yes, using Elements RTL Strings (well, supposedly!).

In other words, I should be using register.stringValue.Length != 0 instead of !register.stringValue.isEmpty() ?

4

Fire really didn’t want to let me use .Length: it changed it automatically to .length, which didn’t work at compile time!

5

Hmm, thats freaky, too.

6

Can you narrow these two down into a simple test case that doesn’t span 3 projects?

7

Sorry the second one. the isEmpty is “as designed”, of course, if you’re using RTL2 String.

8 
import java.util

print("The magic happens here.")

var x = "test"
var y = x.Length
writeLn(y)

works fine for me, in a console app with RTL2.String. compiles, no case mismatch, and runs fine.

9

Yeah it works well if I use .Length, indeed. What threw me off was Fire spontaneously replacing Length with length and Cmd-clicking String and getting the java.lang.String declarations.

10

So what’s the case that failed at runtime? thats the most worrying part.

Oddly, I don’t see that, it shows me RTL2 string’s APIs (albeit with some issues):

image
image2058×1622 466 KB

11

There was no runtime failure, just a compile time error.

If you try Cmd-clicking String in my test project (in SharedProject’s Class.swift file) you should see what I’m referring to.

12

ah, misread.

here’s what I get

image
image2570×1704 915 KB

13

Not sure why we’re having different results:

09
Capture d’écran, le 2019-01-25 Ă  11.32.09.png2570×1704 1 MB

14

And, although I’m sure these are related, this is what I get when I use .Length:

43
Capture d’écran, le 2019-01-25 Ă  13.23.43.png1342×90 8.81 KB

15

I see you’re having the Elements RTL reference show as missing/broken, so the IDE doesn’t know about that. I wonder why. can you click the References node of class library and copy/paste the resolve log?

16

34
Capture d’écran, le 2019-01-25 Ă  13.26.34.png3234×2348 1.39 MB

[and, just to see if it would change anything, I cleared the ~/Library/Application Support/RemObjects Software folder and restarted Fire - it didn’t have any effect]

17

I believe I resolved at least part of the issue: I had uninstalled the separate compiler you sent me earlier this week but Fire still had the ‘use external compiler’ checkbox checked (but greyed out). I quit Fire, reinstalled the external compiler, re-launched Fire, unchecked that checkbox, quit Fire, uninstalled the external compiler and re-launched Fire. They resolve fine now.

18

Odd. I assume building works and resolves it, can you post a (rebuild, diagnostic) log for that too? Do you have the External Compiler installed (and/or enabled) or just internal? And can you post a screenshot of the Paths page of Preference:

image
image.jpg1478×1398 208 KB

and

image
image.jpg1478×1398 166 KB

19

Ah. Was this without a restart of Fire after you removed the external compiler, or did you had you restarted Fire since? When fire starts and the external compiler isn’t found, the checkbox should bake no difference (but I’ll investigate this, maybe there’s a bug there).

20

I restarted it quite a few times after uninstalling the external compiler.

(and doing this seems to have restored the correct code completion behavior as well, obviously)