Question about the new polyglot API and its `Value` class

[Peter Niederwieser]

Hi Jaroslav and Christian,

> - As far as I understand, Peter is not interested in an interface Pojo view
> on JavaScript objects.

That’s correct. Mapping Truffle objects to POJO views is nice but isn't applicable to my use case.

> You can do a lot of language specific things without having an explicit API
> for a particular language feature. For example it is also possible to
> expose a guest language function that covers the language specific use
> case. For example if we don't support removing of properties in the Value
> API. Feel free to just do:
> 
> Value removeProperty = context.eval("js", "(function(o, property) {remove
> o[property];})");
> removeProperty.execute(...)
> 
> For example we used this trick to support certain things that are exposed
> in the javax.scripting API but not yet in the Value API.

This trick works for sufficiently powerful general-purpose languages but may not work for languages that are (intentionally) more limited.

I used to think that a custom message would be a good fit for such a use case. However, last time I checked, the new `Value` API didn't support custom messages. (It also didn't support `invoke`.)
 
> Accessing the raw object is problematic for multiple reasons:
> - We need to enter a particular context for thread local context access
> whenever we cross the boundary from host to guest. Your exposed raw object
> is not doing that. All of our Java interop wrappers ensure that the right
> context is entered.

The raw object would only be accessed as part of evaluation within a context. It would be converted to an immutable data structure which would then be returned to the caller. The immutable data structure wouldn’t allow any further language interaction (so no further crossing of boundaries).

> - It breaks the abstraction of the language implementation. (you make your
> embeddings dependent on language implementation specific API)

Only the `Evaluator` implementation would ever access the raw object, and only to convert it to an immutable data structure.

> If the only reason you are trying to do this is performance, then I would
> appreciate, some benchmarks to reproduce, so I can work with you on these.
> In all the benchmarks that I did internally for embeddings I could remove
> the cost of the polyglot abstraction almost entirely.

The other motivation is that a direct conversion is much easier to implement. I’m not quite sure how to shoehorn a dozen language-internal data types carrying data and metadata into `TruffleObject`s, then convert them back to their external (i.e., Evaluator) API equivalents. But I’ll give it a try.

> BTW.: I have just merged a new PR that makes it more efficient to do many
> operations with the Value API. [1]
> For example you can now do
> context.enter();
> // perform many operations using the polyglot api
> context.leave();

What if after calling `context.enter()`, I would execute a node directly, instead of using the polyglot API? Would this be enough to get `TruffleContext` and time/memory boxing to work?

Thanks,
Peter