Java Values are displayed differently in the Chrome Devtools debugger

[radeusgd]

Consider the following program:

from Standard.Base import all

main =
    d_enso = Date.new 2011 12 13
    d_java = Date.parse "2014-12-15"

    IO.println d_enso
    IO.println d_java

run it with --inspect and set the breakpoint at IO.println d_java.

We will see the following Scope:

We can see that the value coming from Java is displayed differently than the one from Enso, even though both are a Date. It is probably because Enso did not manage yet to perform its polyglot conversions. Shall they be performed before displaying the object?

Another issue can be seen when we interact with the REPL:

We can see that values coming from polyglot calls (e.g. next) behave Java-like and the ones that are 'correctly' displayed come from builtin methods (e.g. Date_Time.date) which ensure the Enso polyglot conversion happens.

---

I'm not sure if this is a bug - although ideally the behaviour of the Debugger should be consistent regardless of where the value is coming from.

What may be especially misleading is that the Java values display all kinds of Java methods they have:

But these methods won't work, because of how the Enso interop works (once we do a call, we do the polyglot conversion and it's no longer a Java LocalDate but an EnsoDate):

That is quite misleading, so I think ideally we should fix it and show the value for what it is to the user - an Enso date. I'm not sure how big of a priority this is though.

[JaroslavTulach]

Enso did not manage yet to perform its polyglot conversions.

Yes, Enso doesn't convert non-primitive values until they need to be converted.

Shall they be performed before displaying the object?

No. The general rule is to convert values as late as possible.

show the value for what it is to the user - an Enso date

There is a concept of a view EnsoLanguage could probably convert those values (for example by passing them to identity function).