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

Use case methods hide information about the actual method #5287

Closed
scabug opened this issue Dec 7, 2011 · 11 comments
Closed

Use case methods hide information about the actual method #5287

scabug opened this issue Dec 7, 2011 · 11 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Dec 7, 2011

Now that use cases hide the actual method, deficiencies in their implementation have become critical. Basically, their whole body is based on the use case definition, so they show up as abstract (whether they are or not), attributes are lost (such as "final"), and the definition classes become useless.

To put it simply, the documentation for all methods with use cases is now BROKEN, in a way that goes way beyond simply displaying a false signature. And, of course, we presently have no way of actually looking up the real signature -- since definition classes is broken, we can't even track the source code for it.

Personally, I consider this issue Critical. The nightly docs are used by a lot of people, but they mostly know how to get around. If, however, a release is made in the current condition, there will be hell to be paid because of these issues.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 7, 2011

Imported From: https://issues.scala-lang.org/browse/SI-5287?orig=1
Reporter: @dcsobral
Affected Versions: 2.10.0

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 8, 2011

@VladUreche said:
Fixed in pull request 46.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 10, 2011

@dcsobral said:
It is not fixed. See List, for instance:

trunk:

Definition Classes GenTraversableLike

2.9.1:

Definition Classes TraversableLike → GenTraversableLike → FilterMonadic

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 10, 2011

@VladUreche said:
Hi Daniel,

What method are you referring to?

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 10, 2011

@VladUreche said:
Now I see what you mean, the Definition Classes field is different for use cases and their corresponding full signatures.

Okay, this is starting to annoy me... Both this problem and the abstract annotation are related to how Symbol is initialized: at the time the use cases are generated, the member's Symbol has flag DEFERRED and is not (completely) initialized. Now I need to find out what exactly needs to be done to force initialization, as cloning it at the time it's DEFERRED yields all these incorrect results. It's funny that the problem was there all along, but nobody noticed the use case problems until I removed the full signatures. :))

Thanks for pointing it out, I'll look into it. Hopefully I'll fix it for good this time.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 12, 2011

@paulp said:

Now I need to find out what exactly needs to be done to force initialization

In general, you call .initialize.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 12, 2011

@paulp said:
But if the situation is really that the info is not up to date (I'm not plugged into the details here) then you might want to call sym.info before you do anything else with it.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 12, 2011

@VladUreche said:
Seems the flags are not forced to the correct values upon calling .initialize. There's something I must be missing here...

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 12, 2011

@paulp said:
Did you do what it says in my second comment?

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Dec 12, 2011

@VladUreche said:
Yes, I did. It turns out we're talking about two different symbols: One that is inserted in the use case by the typer (stored in UseCase.defined) and the actual symbol that scaladoc sees, after the typers phase ran. I would have expected they are the same, but they're not: they share the name, the type but not the flags.

The Usecase symbol is added when typers encounters a DocDef (Typers.scala:4017) by calling typedUseCase on Typers.scala:1643 and setting useCase.defined in Typers.scala:1669.

So the fix should be pretty simple: we need not rely on the symbol set by typers but on the symbol provided by scaladoc. On the other hand, I really want to understand why isn't the UseCase.defined symbol updated properly.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Mar 22, 2012

@VladUreche said:
Closing this bug as a duplicate of #5054, if you notice other strange behaviors in usecases please comment there.

@scabug scabug closed this Mar 22, 2012
@scabug scabug added this to the 2.10.0-M1 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.