Packages names sometimes required

[ncannasse]

https://heaps.io/api/h2d/ObjectFollower.html#new

The constructor is generated as new(obj:Object, ?parent:Object) but its real type is
new(obj:h3d.scene.Object, ?parent:h2d.Object)

I think we should generate explicit package name in documentation when there is such a class in the current (or parent) package. That should also fix for instance someone having a pack.Array class being documented as Array and thus creating confusion.

[Gama11]

I think we should generate explicit package name in documentation when there is such a class in the current (or parent) package.

Not sure I understand that "algorithm", did you mean "isn't"? If so, I think that would be way too noisy. Intuitively, I would only generate the fully qualified name when two or more unqualified type names are identical within a signature.

[ncannasse]

I don't think it's a matter of conflict : if you are in package h2d which has already an Object class but a variable reference a h3d.scene.Object, it should not be listed as Object. But I agree we should not be explicit for every out-of-package path. So my proposal is to do it IF the type name is already used in current package (or any parent package, including root package).

[Gama11]

You could have this exact same problem independent of what the current / parent package is though. Say you have a method a.A.foo(Object, Object), with the first Object referring to b.Object, and the second one to c.Object, you still can't tell that the types are different without hovering over them. My approach would solve that, while yours wouldn't, if I understand it correctly.

[ncannasse]

Both are complementary.

Another way is to use your approach, but instead of per signature, at the level of the whole type definition. I guess that would work too, as long as you don't see "Object" which changes meaning depending on the signature:

For example:

function get2D() : h2d.Object;
function get3D() : h3d.scene.Object;