-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolution through aliases is not supported #28
Comments
Same issue with module type aliases, as well. |
Perhaps actually the same issue as #26? |
In my opinion this behaviour is correct. In all these cases the desired referent is present in the expansion of the module. (By expansion I basically mean signature, but including the equivalent for functors.) It should always be possible to view the expansion of any module. (This is a separate issue from whether that expansion should be displayed inline in the parent expansion). So these links should always have a corresponding location to point to. In terms of implementation, I think that every module (including aliases) should have a corresponding documentation page containing its expansion. All identifiers of the form "module:Foo/module:Bar/foo" should be considered links to the definition of "foo" on the page for "Foo.Bar". This is quite similar to what ocamldoc does currently. In other words expansions should always be available (as a separate page), and references should point to the expansion of the deepest module/module type/class/class type in the path. |
In general, I agree with you. However, there are some cases where this behavior is undesirable. For instance, in your Dep tests, many of these alises are to signatures which are already inline on the page, will always be inline on the page, and have no substitutions or parameterizations. In these cases, it seems strange to point to a page containing only the signature out-of-context. |
So when the expansion is available inlined within the parent then links to it from elsewhere in the parent should go to its inlined expansion rather than its stand-alone expansion. This is reasonable behaviour, but I think it should be handled within OCamlary. OCamlary should be making the decisions about which expansions to inline, so it should make the descisions about which copy of the expansion to point to. I don't think it would be too difficult, you would have to make some kind of table recording which expansions are available inline and then check each identifier against that table before turning it into the appropriate link. |
Sounds reasonable. Closing in favor of dsheets/codoc#23. |
but
Alias.t
points to#/module:Alias/type:t
.I don't know how related this is to #2.
The text was updated successfully, but these errors were encountered: