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
general problem with figuring out when to show a fully qualified name and when not to #4360
Comments
Imported From: https://issues.scala-lang.org/browse/SI-4360?orig=1 |
@heathermiller said: In general, self-contained and minimized code examples are what we need to issue a fix. Can you please submit a self-contained (i.e. not dependent on ScalaTest source) example? |
@VladUreche said (edited on May 7, 2012 11:19:25 AM UTC): $ cat A.scala
package a {
class A
}
package b {
class A
}
$ scalac A.scala
$ cat B.scala
package a {
class B {
def fooA(a: A) = 3
def fooB(a: b.A) = 4
}
}
$ scaladoc B.scala
model contains 3 documentable templates In the scaladoc page you'll get: def fooA(a: A): Int
def fooB(a: A): Int The tooltips will indicate the correct entities (a.A and b.A) but that doesn't make it much better. |
@heathermiller said: So, I suppose, in an effort to support fully-qualified names being generated in some scenarios, but not in others (we don't want them generated all over the place when they don't need to be) we could at the entity-level: check if there are two or more types that appear with the same name, if so, compare the fully-qualified names, and append the prefixes to the entity name as follows: scala.collection.immutable.HashMap -> immutable.HashMap
scala.collection.mutable.HashMap -> mutable.HashMap
org.scalay.collection.immutable.HashMap -> org.scalay.collection.immutable.HashMap It's certainly possible, but the way I see to do it is to, as we produce the page template in Template.scala for a given entity, collect the fully-qualified names of every type/entity we encounter (i.e. param lists of members, return types, etc) in a Set or something private and top-level in Template.scala. But then the issue is that afterwards, we'd need to make a second pass through the whole page and rewrite duplicate-named entities with the qualified/fully-qualified names, where necessary. ...Which would require a larger refactoring... (Unless there's an easier way to do it that I'm missing, maybe in the model or something...) But... Workaround: in the meantime, one could use a use-case to insert better-qualified/fully-qualified names where needed. |
@VladUreche said: How would you work around this with use cases? |
@VladUreche said: |
=== What steps will reproduce the problem (please be specific and use wikiformatting)? ===
=== What is the expected behavior? ===
fully qualified name:
org.hamcrest.Matcher
=== What do you see instead? ===
Matcher
=== Additional information ===
(for instance, a link to a relevant mailing list discussion)
In JMockSugar. some of the methods take a Matcher, but it just says
Matcher. Well that's a org.hamcrest.Matcher, not a
org.scalatest.Matcher, and there's no way to tell from the
documentation
=== What versions of the following are you using? ===
Scala: Scala code runner version 2.8.1.final -- Copyright 2002-2010, LAMP/EPFL
Java: java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.7) (fedora-50.1.8.7.fc13-i386)
OpenJDK Server VM (build 14.0-b16, mixed mode)
Operating system: Linux localhost.localdomain 2.6.34.8-68.fc13.i686.PAE SI-1 SMP Thu Feb 17 14:54:10 UTC 2011 i686 i686 i386 GNU/Linux
The text was updated successfully, but these errors were encountered: