Decouple responsibilities of Source class about graal HOT 4 CLOSED

I am currently working on cleanup of Source creation sequence. I am going to introduce Source.Builder, draft is available at https://github.com/jtulach/truffle/tree/SourceBuilder

The builder will not use any caching - e.g. your point 2 will be satisfied.

I find the description of point 1 a little bit too vague (unless it means "set the URI for a Source") - hard to guess whether my work satisfies it.

from graal.

To give some more background, I replaced 1 and 2 with my own code because:

1. I wanted Source to behave uniformly regardless of which origin it was loaded from, in terms of eager vs. lazy loading, caching, etc.
2. I wanted to support the following different kinds of source code origins specific to my language: URL, File, class path, standard library, REPL input, literal text
3. I wanted to easily determine the origin of a piece of source code and query its origin-specific attributes (e.g. to perform permission checks and to resolve relative script includes in an origin-specific way), without having to reconstruct this information from a Source's answers to getURL, getPath, getName, etc. (which is brittle).
4. I wanted to have my own implementations for loading code from an origin (e.g. to perform permission checks and to leverage non-blocking IO).
5. I needed to have my own representation of source (origin) anyway, as leaking Truffle classes from my APIs wasn't an option.

To satisfy these requirements, I currently do the following: I do my own loading/caching, exclusively use Source.fromText to create Source objects, and keep origin-specific information about the source in an IdentityHashMap for later lookup. This works reasonably well. However, I'd rather not have to use IdentityHashMap, and complications arise when I need to process a Source that wasn't created by my own code. (I'd like to support this in order to be a good Truffle citizen.)

The following enhancements to Source could make it a more versatile abstraction and a better fit for my needs:

1. Allow to attach opaque meta-information to a Source.
2. Allow to easily determine which kind of built-in origin (fromURL, fromFilename, fromText, etc.) it was loaded from and what the origin-specific attributes are.

I also considered proposing a first-class, user-extensible notion of source origin, but this might not work so well in a polyglot setting.

from graal.

After jtulach@872a1e9 the origin is taken uniformly, I'd say.

The additional meta-information is out of scope for the current "builder" change, but it is an interesting idea. Similar to: when a co-located source is about to be loaded (think of importScript('rel.js')) shouldn't that request be handled by the one who created the source that contains the importScript?

from graal.

Looks like a stale issue where most issues are already resolved. Please reopen if addition work is necessary.

from graal.