Analyzer packages: why re-implement common utilities?

[Patt O'Brien]

Hi Analyzer team,

The question I have can be focused on the re-implementation of types: Resource / Folder / File. We can focus on these, while I believe the same argument applies to SourceSpan (from package:source_span), and possibly others.

There's a dart package "file", that seems to have all features that ResourceProvider requires (incl. in-memory file system representation). As I continue to create my own analyzer plugin, its been a bit overhead to work with several different implementations of the file system; for example: package:glob uses package:file, and therefore the Glob utilities cannot read from the in-memory resource provider from analyzer. I assume the Dart ecosystem strives to use consistent abstractions of basic utilities, so I'm wondering if there's a reason for not doing so in this case? 

Thanks in advance -

Patt

[Brian Wilkerson]

The answer for `Resource` and `SourceSpan` is the same: we didn't use those packages because they didn't exist when we implemented our equivalents. And while we could presumably switch to using those packages now, it would be a large undertaking that we don't have any plan to take on at this point (and because of internal use cases it isn't something that an external contributor could do for us).

I'm sorry that it's causing problems. It might be possible to implement `FileSystem` on top of `ResourceProvider` as a bridge for the other APIs, and that might ease some of the pain.

--
You received this message because you are subscribed to the Google Groups "Dart Analyzer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discu...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/analyzer-discuss/01f46302-e7d5-409f-a665-629343ba341fn%40dartlang.org.