Skip to content
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

Closed
dsheets opened this issue Dec 8, 2014 · 6 comments
Closed

Resolution through aliases is not supported #28

dsheets opened this issue Dec 8, 2014 · 6 comments

Comments

@dsheets
Copy link
Contributor

dsheets commented Dec 8, 2014

module Simple : sig
  type t
  type u
end

module Alias = Simple

type alias_t = Alias.t

but Alias.t points to #/module:Alias/type:t.

I don't know how related this is to #2.

@dsheets
Copy link
Contributor Author

dsheets commented Dec 8, 2014

Same issue with module type aliases, as well.

@dsheets
Copy link
Contributor Author

dsheets commented Dec 8, 2014

Perhaps actually the same issue as #26?

@lpw25
Copy link
Collaborator

lpw25 commented Dec 8, 2014

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.

@dsheets
Copy link
Contributor Author

dsheets commented Dec 8, 2014

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.

@lpw25
Copy link
Collaborator

lpw25 commented Dec 8, 2014

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.

@dsheets
Copy link
Contributor Author

dsheets commented Dec 8, 2014

Sounds reasonable. Closing in favor of dsheets/codoc#23.

@dsheets dsheets closed this as completed Dec 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants