Integrate foreign objects better with Ruby objects

[eregon]

Currently, foreign objects are handled specially in OutgoingForeignCallNode.
They are given a Ruby class, Truffle::Interop::Foreign but actually methods are not looked there, all method calls are directly dispatched to OutgoingForeignCallNode instead.

I think a better design would be to have a set of modules and classes for foreign objects, and make foreign objects behave more like Ruby objects by using the normal Ruby method lookup.
When a Ruby method would not be found, we would check members with isMemberInvocable and either invokeMember or readMember, instead of calling method_missing.

So we could have something like Polyglot::ForeignArray < Polyglot::ForeignObject < Object and Polyglot::ForeignArray would include Enumerable.
Then we could easily define the logic in Ruby.
All Object , Kernel, and BasicObject methods should then also handle foreign objects.

Given that a foreign object might have multiple traits:
https://github.com/oracle/graal/blob/68ce20c37071cfa91146f437eb6ab6ccffbd0759/truffle/src/com.oracle.truffle.api.interop/src/com/oracle/truffle/api/interop/InteropLibrary.java#L129-L145
we should probably use modules to represent those traits that map to Ruby concepts.

So we'd have module Polyglot::Trait::ForeignArray, module Polyglot::Trait::ForeignProc, etc.
And we'd need classes to compose them like (an object must be the instance of a class, not of a module)

module Polyglot::Trait::ForeignArray
  include Enumerable
  def each
    ...
  end
end

class Polyglot::ForeignArray < Polyglot::ForeignObject
  include Polyglot::Trait::ForeignArray
end

class Polyglot::ForeignArrayProc < Polyglot::ForeignObject
  include Polyglot::Trait::ForeignArray
  include Polyglot::Trait::ForeignProc
end

(just a sketch, we might want to think more about names)

foreign_object.class would actually return one of these classes, and we'll need an efficient way to compute that as it would be used for every method call on a foreign object.
Internally, to get the class of a foreign object, we'd probably want to add RubyLibrary#getMetaClass() and RubyLibrary#getLogicalClass() and implement them for foreign objects.

cc @rbotafogo @fniephaus @chumer

[eregon]

It might be better to inherit from the core Ruby types actually, like class Polyglot::ForeignArray < Array, and Polyglot::ForeignObject could just be a module instead (or more simply a trait). That means things like foreign_array.is_a?(Array) would be true. But we can only inherit from one class, so we'd have to find the "primary trait" or so.

[fniephaus]

In theory, you could generate all sorts of Ruby classes each with a different combination of traits. On class lookup, TruffleRuby could return the best possible fit depending on the interop properties of the foreign object (e.g. hasArrayElements and such). That still wouldn't get you past the inheritance problem, so is_a? calls might need to be special-cased for foreign objects as well (e.g. returns true if Array or Exception depending on its interop props).

[eregon]

In theory, you could generate all sorts of Ruby classes each with a different combination of traits

Right, it would be nice if they have a name though, for inspection/debugging. But we could generate the classes dynamically from Java or from Ruby I suppose. I think initially I'd keep it static while we have few traits handled in Ruby.

That still wouldn't get you past the inheritance problem, so is_a? calls might need to be special-cased for foreign objects as well (e.g. returns true if Array or Exception depending on its interop props).

That's a good point, handling foreign object specially in is_a?/kind_of?/Module#=== would be one possibility.
However it kind of breaks the consistency of "foreign objects are just like Ruby objects with a Polyglot::Foreign* class + extra methods (which we should probably report in Kernel#methods).

[rbotafogo]

I tried to implement some of the ideas, but had the following two problems:

1. class ForeignArray was implemented inside of array.rb file. This is clearly wrong, but I didn't find yet a way of requiring a new file when lauching.
2. Where in the directory hierarchy should ForeignObject, ForeignArray, and all the traits be added?