Add back type_of_class_type injection

[dsheets]

Went missing recently.

[lpw25]

Since all of the removed injections were removed because they did not make sense within my model of what all the types means, I would be grateful if you could show me where it is needed in your code. That way I can figure out where my model is disagreeing from how you are using them in practice.

[dsheets]

It's used by polymorphic class type constructors. See https://github.com/dsheets/ocamlary/blob/master/lib/ocamlaryDocHtml.ml#L1096.

[lpw25]

Is the call totype_of_class_type actually needed there? It looks like of_type_constr is polymorphic in the type of its path parameter -- since path is only used in calls to Path.any.

[dsheets]

It could accept any path type... but then why do we have this intricate hierarchy? Isn't a class type a type? What's wrong with this injection?

[lpw25]

Isn't a class type a type?

Not really. Internally when you define a class type there are three signature items added to the signature (although the printing code hides two of them -- see Mantis issue 6654 for a case where this fails and the ugly underbelly of OCaml is revealed). This is why I removed the coercion.

However, there is a corresponding type path for each class type path (the one defined in the same place), and it is not unreasonable to think of printing #foo as printing a # and then printing the type path that corresponds to the class type foo. So I think you are right and we should replace this coercion.

[lpw25]

Not really. Internally when you define a class type there are three signature items added to the signature (although the printing code hides two of them -- see Mantis issue 6654 for a case where this fails and the ugly underbelly of OCaml is revealed). This is why I removed the coercion.

To be a bit clearer, since there are multiple signature items there are multiple paths (and internally the paths are indeed different).

[lpw25]

To be even mode clear.

The coercions that I left in after the recent changes (e.g. Identifier.signature_of_module, Reference.class_signature_of_class_type) are genuine subtype coercions -- a module identifier is a signature identifier, a class type reference is a class signature reference.

Whereas type_of_class_type is not a subtyping coercion -- a class type path is not a type path. However, there is a reasonable function which takes a class type path and returns the type path that was defined in the same place, and the reinstated type_of_class_type is that function.

Hopfully that makes my thinking more clear.