An alternative would be to have named provide specifications. That way we could tell one client to use API R and another client to use API TR to access functions from our module. If we do this right, we can connect submodules to such provides and nobody will ever know that they are requiring a submodule.
-- Matthias On Jul 6, 2015, at 7:27 AM, Alexis King wrote: > Exposing submodules is becoming more prevalent in Racket, and I think that may > be a good thing. The downside is that the syntax for requiring a submodule > outside of its defining module is a bit clunky (the use of `submod` is > necessary). The same would be true for `lib`, but Racket already has sugar for > `lib` in the form of symbolic module paths, which is obviously the most common > way to specify modules. > > Since the grammar for these paths already constrains the characters they may > contain, it would be completely feasible to add a little more sugar to make > requiring submodules easier. To make this more concrete, something like > (require foo/bar:baz) could be equivalent to (require (submod foo/bar baz)). > > I, myself, have two main thoughts about this, having already considered it > somewhat. > > 1. I think this would elevate submodules to a more commonly-used feature. > Right now, aside from main and test submodules, they rarely pop up, mostly > because there’s little need most of the time, and using them is verbose. > However, since modules themselves are intrinsically tied to the > filesystem, > sometimes it’s nice to not need to create a full module. > > 2. There is a downside to this (aside from the obvious potential downside of > cluttering the module path with more syntax): it makes it much easier to > expose submodules as part of a public API, but still forces the consumer > of a module to be aware of the difference between a module and a > submodule. > > This means that a user needs to remember if a module path is foo/bar or > foo:bar, depending on whether or not the author used a submodule, and it > also means there is not a seamless path for moving a submodule to a full > module or vice-versa. > > The above caveat is real, but I still think it could be advantageous all the > same. Thoughts? Questions? Concerns? > > Alexis > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/5D260BC4-FA07-4668-919D-92A6B3DC9DB4%40gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/2AD9E5E4-DB2C-4D9E-BE69-69C07A43BE4C%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
