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

scaladoc: Map -> flatMap (use case) #3448

Closed
scabug opened this issue May 17, 2010 · 4 comments
Closed

scaladoc: Map -> flatMap (use case) #3448

scabug opened this issue May 17, 2010 · 4 comments
Assignees

Comments

@scabug
Copy link

scabug commented May 17, 2010

this is described as:

 def flatMap[B](f: ((A, B)) => Traversable[B]): Map[B]

obviously Map[B] doesn't exist, and it should probably be something like Iterable[B]?

@scabug
Copy link
Author

scabug commented May 17, 2010

Imported From: https://issues.scala-lang.org/browse/SI-3448?orig=1
Reporter: @Sciss

@scabug
Copy link
Author

scabug commented May 19, 2010

@axel22 said:
Indeed. This is in fact the case with all the methods taking an implicit builder factory, not just flatMap.

Doc comments can only be overridden if the method gets overridden, but one should not override all these methods in MapLike just to get the comments right. A solution would be to manually specify the dynamic return type macro named $$FactoryResult and use that instead of $$Coll in the use case.

@scabug
Copy link
Author

scabug commented May 19, 2010

@axel22 said:
But that would mean having to redefine macro FactoryResult along with Coll and coll in all the collection classes.

@scabug
Copy link
Author

scabug commented Jul 23, 2012

@VladUreche said:
This is quite tricky to fix. Redefining the use case won't work, and I tried getting the correct type back in 891769fa:

/**
 * @define Coll Iterable
 */
class Iterable[T] {
  /**
   * @usecase def foo[T]: $Coll[T]
   */
  def foo[T: Numeric]: Iterable[T]
}

/**
 * @define Coll D1
 */
class Map[A, B] extends Iterable[(A,B)] {
  protected type D1[_] = Map[A, B]
}

But that won't work well, as the return type of function f is not constrained to be (A,B) => (C,D).

So, I'll close this bug as won't fix, and I created bug #6128 about making the use case generation fully automatic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants