You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
=== What steps will reproduce the problem? ===
Try linking to anything other than a class with ScalaDoc.
=== What is the expected behavior? ===
Links should be able to point to classes, objects(!), methods.
Choosing the right method in case of overloading should be supported.
=== What do you see instead? ===
It doesn't work, there is neither a specification in case anyone plans to implement it.
=== Additional information ===
Having thought about this, afaiu we can't follow Java's path of using "." for static methods/fields and "#" for instance methods/fields because of path-dependant types.
A thinkable worst-case could be something like this:
packageFooclassFoo {
classBardefBar=0
}
packageFoo.BarclassBarobjectBar
Now add package objects on top of that.
It would be possible to use things like foo(Int,String) for overload resolution of methods, comparable to Java.
The text was updated successfully, but these errors were encountered:
@soc said:
Also, coming up with a way to link to objects itself (without method call) would be nice.
{{scala.None}} is a good example. Maybe it would be possible to use the not-invented-yet char for object method/field access for differentiating between class/object? (If "@" would be the char, something like {{scala.None@}}?)
=== What steps will reproduce the problem? ===
Try linking to anything other than a class with ScalaDoc.
=== What is the expected behavior? ===
Links should be able to point to classes, objects(!), methods.
Choosing the right method in case of overloading should be supported.
=== What do you see instead? ===
It doesn't work, there is neither a specification in case anyone plans to implement it.
=== Additional information ===
Having thought about this, afaiu we can't follow Java's path of using "." for static methods/fields and "#" for instance methods/fields because of path-dependant types.
A thinkable worst-case could be something like this:
Now add package objects on top of that.
It would be possible to use things like
foo(Int,String)
for overload resolution of methods, comparable to Java.The text was updated successfully, but these errors were encountered: