stefnotch
commented
1 month ago So in terms of proposals, we've had
modstatements everywhere, which makes inline pathing just a special case. Rejected due to it interacting in inconvenient ways with projects that scatter their WESL code all around.- Glob maps: Tells us all files to look up. Not applicable in a web case though.
And currently I believe we have
- Module map: Tells us which file to look at when resolving a module. Inline modules don't need an extra entry. Writing a module map is ideally tool-assisted.
- Separate separators for file/path and inline::modules. May make sense, since they behave slightly differently as @k2d222 pointed out. Makes WESL-to-WESL-bundling a bit tricky; probably requires rewriting paths or an extra syntax.
- Each module defines how to interpret paths "below" it. There are two separate sensible defaults
- "mod ..." being the default. To resolve "foo/bar/baz", we look at "foo.wesl", then "foo::bar.wesl" and then "foo::bar::baz.wesl".
- "file path" being the default. To resolve "foo/bar/baz.wesl", we look at "foo.wesl". Since the rest is a file path, we immediately jump to "foo/bar/baz.wesl".
- Inline modules only work if reached through modules. With the "mod ..." default, that would almost always be the case.
- Web projects would frequently use the file paths everywhere, and not use inline modules in their code. This means that we should probably provide an alternative syntax for generic modules, to avoid locking them out of that feature.
Does this cover everything, or did I forget any options? I'll happily write up a more concrete proposal for any of the options.
Is there a way to introduce inline pathing to the specification?
Bevy users have become used to this convenience and it'd be quite useful for generic modules, in which you could think of a submodule or submodule alias as a sort of associated type.