Decouple responsibilities of Source class

[pniederw]

Currently, Source has at least three distinct responsibilities:

1. Load source code from different origins
2. Cache source code once loaded
3. Work with source text (SourceSection, etc.)

I'm happy with how Source handles 3, but have different requirements for 1 and 2 (i.e. I need full control over them). Can these responsibilities be extracted into separate classes (e.g. SourceLoader) that are not mandatory for using the PolyglotEngine/TruffleLanguage/Source APIs? Also, can you add a way to set the URI for a(ny) Source, so that its origin can be cleanly attached?

[jtulach]

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.

[pniederw]

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.

[jtulach]

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?

[chumer]

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