OptionalroleThe role of this file, if any, in general your file should not decide for itself what role it has in the project context, this is for the loaders plugins to decide (cf. PluginType) as they can, e.g., respect ignore files, updated mappings, etc. However, they will 1) set this role as soon as they decide on it (using assignRole) and 2) try to respect an already assigned role (however, user configurations may override this).
Assign a role to this file, this should be done by the loader plugins (cf. PluginType). Do not call this method yourself unless you are a file-loader plugin and/or really know what you are doing, this may break plugin assumptions!
The content of the file, this may be cached by the implementation and does not have to be expensive. You can used stream based implementations but right now there is no external, project-wide expressions of life cycles for files. So make sure your implementation closes the resource as soon as possible.
The path to the file, this is used for identification and logging purposes. If the file does not exist on disk, this can be a virtual path (e.g. for inline files). Even though this is a getter, please make sure that the operation is cheap and deterministic (some decorators may overwrite the path, e.g., because they support other protocols).
This is the basic interface for all files known to the FlowrAnalyzer. You can implement this interface to provide custom file loading mechanisms. Mostly, we will be interested in text files (or decorations thereof). If you want to load other file types, you either have to transform them into a presentation supported by flowR or add your own file loader plugin (similar to the FlowrAnalyzerDescriptionFilePlugin).
See FlowrFile for a basic single-cache implementation and FlowrTextFile for a text-file specific implementation. If you want to pass in inline text files, see FlowrInlineTextFile.