You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #7858 was implemented, we can use polyglot java import types (e.g. host Java classes) in type ascriptions. The host Java classes are recognized in Meta.type_of and we can even use them in case of statements:
However there are still few areas where the support of host Java classes isn't on par with Enso types - one cannot add extension methods to them and one cannot define conversion methods. Both of these features are technically possible and they would smooth interoperability between Enso and Java when designing the Enso libraries.
The text was updated successfully, but these errors were encountered:
it makes little sense to invest in making Java types first class citizens in Enso. As it is not going to be possible to exchange an object from NI with object from JVM - even if they have the same java.lang.Class they will be different.
Based on the #8346 (comment) idea.
Since #7858 was implemented, we can use
polyglot java import
types (e.g. host Java classes) in type ascriptions. The host Java classes are recognized inMeta.type_of
and we can even use them incase of
statements:However there are still few areas where the support of host Java classes isn't on par with Enso types - one cannot add extension methods to them and one cannot define conversion methods. Both of these features are technically possible and they would smooth interoperability between Enso and Java when designing the Enso libraries.
The text was updated successfully, but these errors were encountered: