The current implementation of cross_file relies on cross-platform constructors that "need to work" across all platforms. With time, and as features are added, these constructors end up growing, and now some parameters are being ignored by some platforms and used by others. This causes confusion/problems.

It seems that cross-platform constructors are not the way to go for this particular package; instead XFile users should be able to choose what factory they need for the platform that they're implementing. So, in places where dart:io is available, they could do:

XFileIO.fromFile(io.File file) or XFileIO.fromPath(String path)

But if dart:html is available

XFileWeb.fromHtmlFile(html.File file) or XFileWeb.fromBlob(html.Blob blob, String name) or XFileWeb.fromBlobUrl(String blobUrl, String name, int length...)...

or any other "specialty" constructors that would make sense per platform.

The XFile class that most people use would end up being a read-only interface to retrieve data from the file, and the different backing implementations would extend it.

(This would also allow us to return XFile as the base-class name for all the objects, instead of being the top-most classname, which is weird from an OOP standpoint!)

Some questions:

• What to do when the user wants to modify the contents of a file programmatically?
• How to perform those operations so the modified file still uses an efficient backend?
• Should we keep an "inefficient" Uint8List-backed constructor so people can build raw files from memory?