Problem showing deprecation corretly // AW: wrong javadoc for overloaded methods

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem showing deprecation corretly // AW: wrong javadoc for overloaded methods

Kaintantzis, Nikolaos
Hi

I have a problem with deprecating an overloaded method.

- If the deprecated method is the first one, all overloaded methods are shown stroked through in the editor.
- If the first method is not deprecated, the usage of the deprecated method is not visualized with strike through in the editor.

This is maybe the same or a similar thing as the javadoc problem described in the mail below.


I understand that Groovy's dynamic dispatch makes it hard to find the right method in reasonable time.
In our case normally the argument types are known. E.g. because of using the concrete class when declaring a variable. I would be really happy when in such a case the right deprecation information or javadoc is chosen.
(I personally would be quite happy when -- as quick fix -- at least the number of arguments of the overloaded methods is concerned when looking for deprecations or javadoc.)


Cheers
Niko

________________________________________
Von: Kaintantzis, Nikolaos [[hidden email]]
Gesendet: Dienstag, 14. September 2010 09:04
Bis: [hidden email]
Betreff: AW: [groovy-eclipse-plugin-user] AW: wrong javadoc for overloaded methods

Thank you

I've opened a new issue: http://jira.codehaus.org/browse/GRECLIPSE-831

I our case the correctness is important. The users of our product will script using our groovy facades. The javadoc is their entry point for the system documentation.

Cheers
Niko


________________________________________
Von: [hidden email] [[hidden email]] im Auftrag von Andrew Eisenberg [[hidden email]]
Gesendet: Montag, 13. September 2010 18:42
An: [hidden email]
Betreff: Re: [groovy-eclipse-plugin-user] AW: wrong javadoc for overloaded methods

This may not be as easy as it seems.  Because of Groovy's dynamic
dispatch, it is very, very difficult to statically determine what
field/method/property/closure is called at runtime.

So, the problem comes from when hovering over an identifier, we need
to figure out what this identifier resolves to.  Currently, when there
is overloading occurring, we simply pick the first one.  There is
certainly more that we can do, but as with many things, there is a
tradeoff between responsiveness and correctness (ie- the more correct
we make things like mouse hovers and navigation, the longer it will
take to calculate this).

But, it is certainly worthwhile to open a bug report and we can hash
out some solutions for this.

On Mon, Sep 13, 2010 at 8:03 AM, Andy Clement <[hidden email]> wrote:

> Yep, open a bug.
>
> The handling for javadoc is a little weak because we patch the groovy
> compiler (which normally throws comments away) - and to limit the size
> of the patch we take a crude approach.  I think this case could be
> made to work without needing to do the full grammar overhaul.
>
> Andy
>
> On 13 September 2010 01:38, Kaintantzis, Nikolaos <[hidden email]> wrote:
>> Hi all
>>
>> I've extracted the problem into a mini example. Shall I open a new bug
>> report?
>>
>> see you
>> Niko Kaintantzis
>> -----
>>
>>
>> /**
>>
>> * This is my class to show the problem with javadoc.
>>
>> * the javadoc of insert in the two lines c.insert, in the method create,
>> shows the wrong javadoc
>>
>> */
>>
>> class
>>
>> MyClass {
>>
>> static MyClass create(MyClass sample) {
>>
>> MyClass c =
>>
>> new MyClass()
>>
>> c.insert
>>
>> "value"
>>
>> c.insert(
>>
>> "value")
>>
>> return c
>>
>> }
>>
>> /**
>>
>> * Inserts a copy of the specified String to myClass using the given key
>>
>> *
>>
>> @param key the key to refer to the String in the class
>>
>> *
>>
>> @param string the String to be added to the class
>>
>> */
>>
>> void insert(String key, String string) {
>>
>> //do something
>>
>> }
>>
>> /**
>>
>> * Inserts a copy of the specified String to the myClass using no key
>>
>> *
>>
>> @param string the String to be added to the class
>>
>> */
>>
>> void insert(String string) {
>>
>> insert(
>>
>> null, series)
>>
>> }
>>
>> }
>>
>>
>>
>> ________________________________
>> Von: Kaintantzis, Nikolaos [[hidden email]]
>> Gesendet: Montag, 6. September 2010 16:06
>> An: [hidden email]
>> Betreff: [groovy-eclipse-plugin-user] wrong javadoc for overloaded methods
>>
>> Hi all
>>
>>
>>
>> Our product includes the groovy editor (2.0.2) for editing groovy files. It
>> also includes some own groovy façade classes with methods having equal name
>> but different signatures.
>>
>> Given now a user script using a façade and one of these overloaded methods,
>> the javadoc shown by the groovy editor is always the one of the first method
>> in the groovy file.
>>
>>
>>
>> Concrete: The GroovyCompilationUnit.codeSelect returns the wrong
>> JavaElement[]
>>
>>
>>
>> In CodeSelectRequestor.acceptASTNode it ends up in the branch:
>>
>> // try something else because source location not set right
>>
>> and there it only works with the method name and calls findElement(IType
>> type, String text)
>>
>> I’ve changed locally the method to check the parameters received via
>>
>> "((MethodNode) result.declaration).getParameters()",
>>
>> but I then found out that the result candidate is the wrong candidate. Now
>> it’s not the first bit still the wrong Javadoc…
>>
>>
>>
>> Is there any fix I can apply?
>>
>>
>>
>> Thanks
>>
>> Nikolaos Kaintantzis
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Problem showing deprecation corretly // AW: wrong javadoc for overloaded methods

Andrew Eisenberg
Since this is becoming more of an issue for you, we will schedule this
for the next release.  Can you please update the bug report with an
example of your deprecation problem?

On Thu, Apr 28, 2011 at 4:26 AM, Kaintantzis, Nikolaos <[hidden email]> wrote:

> Hi
>
> I have a problem with deprecating an overloaded method.
>
> - If the deprecated method is the first one, all overloaded methods are shown stroked through in the editor.
> - If the first method is not deprecated, the usage of the deprecated method is not visualized with strike through in the editor.
>
> This is maybe the same or a similar thing as the javadoc problem described in the mail below.
>
>
> I understand that Groovy's dynamic dispatch makes it hard to find the right method in reasonable time.
> In our case normally the argument types are known. E.g. because of using the concrete class when declaring a variable. I would be really happy when in such a case the right deprecation information or javadoc is chosen.
> (I personally would be quite happy when -- as quick fix -- at least the number of arguments of the overloaded methods is concerned when looking for deprecations or javadoc.)
>
>
> Cheers
> Niko
>
> ________________________________________
> Von: Kaintantzis, Nikolaos [[hidden email]]
> Gesendet: Dienstag, 14. September 2010 09:04
> Bis: [hidden email]
> Betreff: AW: [groovy-eclipse-plugin-user] AW: wrong javadoc for overloaded methods
>
> Thank you
>
> I've opened a new issue: http://jira.codehaus.org/browse/GRECLIPSE-831
>
> I our case the correctness is important. The users of our product will script using our groovy facades. The javadoc is their entry point for the system documentation.
>
> Cheers
> Niko
>
>
> ________________________________________
> Von: [hidden email] [[hidden email]] im Auftrag von Andrew Eisenberg [[hidden email]]
> Gesendet: Montag, 13. September 2010 18:42
> An: [hidden email]
> Betreff: Re: [groovy-eclipse-plugin-user] AW: wrong javadoc for overloaded methods
>
> This may not be as easy as it seems.  Because of Groovy's dynamic
> dispatch, it is very, very difficult to statically determine what
> field/method/property/closure is called at runtime.
>
> So, the problem comes from when hovering over an identifier, we need
> to figure out what this identifier resolves to.  Currently, when there
> is overloading occurring, we simply pick the first one.  There is
> certainly more that we can do, but as with many things, there is a
> tradeoff between responsiveness and correctness (ie- the more correct
> we make things like mouse hovers and navigation, the longer it will
> take to calculate this).
>
> But, it is certainly worthwhile to open a bug report and we can hash
> out some solutions for this.
>
> On Mon, Sep 13, 2010 at 8:03 AM, Andy Clement <[hidden email]> wrote:
>> Yep, open a bug.
>>
>> The handling for javadoc is a little weak because we patch the groovy
>> compiler (which normally throws comments away) - and to limit the size
>> of the patch we take a crude approach.  I think this case could be
>> made to work without needing to do the full grammar overhaul.
>>
>> Andy
>>
>> On 13 September 2010 01:38, Kaintantzis, Nikolaos <[hidden email]> wrote:
>>> Hi all
>>>
>>> I've extracted the problem into a mini example. Shall I open a new bug
>>> report?
>>>
>>> see you
>>> Niko Kaintantzis
>>> -----
>>>
>>>
>>> /**
>>>
>>> * This is my class to show the problem with javadoc.
>>>
>>> * the javadoc of insert in the two lines c.insert, in the method create,
>>> shows the wrong javadoc
>>>
>>> */
>>>
>>> class
>>>
>>> MyClass {
>>>
>>> static MyClass create(MyClass sample) {
>>>
>>> MyClass c =
>>>
>>> new MyClass()
>>>
>>> c.insert
>>>
>>> "value"
>>>
>>> c.insert(
>>>
>>> "value")
>>>
>>> return c
>>>
>>> }
>>>
>>> /**
>>>
>>> * Inserts a copy of the specified String to myClass using the given key
>>>
>>> *
>>>
>>> @param key the key to refer to the String in the class
>>>
>>> *
>>>
>>> @param string the String to be added to the class
>>>
>>> */
>>>
>>> void insert(String key, String string) {
>>>
>>> //do something
>>>
>>> }
>>>
>>> /**
>>>
>>> * Inserts a copy of the specified String to the myClass using no key
>>>
>>> *
>>>
>>> @param string the String to be added to the class
>>>
>>> */
>>>
>>> void insert(String string) {
>>>
>>> insert(
>>>
>>> null, series)
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> ________________________________
>>> Von: Kaintantzis, Nikolaos [[hidden email]]
>>> Gesendet: Montag, 6. September 2010 16:06
>>> An: [hidden email]
>>> Betreff: [groovy-eclipse-plugin-user] wrong javadoc for overloaded methods
>>>
>>> Hi all
>>>
>>>
>>>
>>> Our product includes the groovy editor (2.0.2) for editing groovy files. It
>>> also includes some own groovy façade classes with methods having equal name
>>> but different signatures.
>>>
>>> Given now a user script using a façade and one of these overloaded methods,
>>> the javadoc shown by the groovy editor is always the one of the first method
>>> in the groovy file.
>>>
>>>
>>>
>>> Concrete: The GroovyCompilationUnit.codeSelect returns the wrong
>>> JavaElement[]
>>>
>>>
>>>
>>> In CodeSelectRequestor.acceptASTNode it ends up in the branch:
>>>
>>> // try something else because source location not set right
>>>
>>> and there it only works with the method name and calls findElement(IType
>>> type, String text)
>>>
>>> I’ve changed locally the method to check the parameters received via
>>>
>>> "((MethodNode) result.declaration).getParameters()",
>>>
>>> but I then found out that the result candidate is the wrong candidate. Now
>>> it’s not the first bit still the wrong Javadoc…
>>>
>>>
>>>
>>> Is there any fix I can apply?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Nikolaos Kaintantzis
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email