syntax hilighting strangeness

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

syntax hilighting strangeness

Jayet, Patrick
Hi all,
 
I have noticed a little problem in the syntax hilighting with respect to objects we get from
a getAt(..) method. Let me introduce an example:
 

class A {

    B getB() {

        return new B()

    }

    B getAt(String s) {

        return new B()

    }

}

 

class B {

    void sayHi() {

        println "hi"

    }

}

 

A a = new A()

 

def b1 = a.getB() // (a)

b1.sayHi()

 

def b2 = a["foo"] // (b)

b2.sayHi()

 

B b3 = a["bar"] // (c)

b3.sayHi()

 

What we can see is:

- The class A defines two methods returning an object B

- When calling getB() on line (a), the return type is correctly inferred and the call to sayHi() on the next line is not underlined

- When calling the getAt method using the square bracket notation (line (b) and (c)), the returned type is messed up and the following lines show a call to sayHi() being not recognized (hence underlined)

- Even in the case of line (c), when we statically declare b3, the call to sayHi() is not correctly recognized

- The code completion is also not working properly. While it thinks b1 is of type B (suggesting the method sayHi), it thinks that b2 and b3 are of type A (suggesting the methods getB).

 

Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira ticket?

 

Thanks in advance.

Cheers,

 

Patrick

 

Reply | Threaded
Open this post in threaded view
|

Re: syntax hilighting strangeness

Andrew Eisenberg
Hi,

This is a bug.  The inferencing engine does not take this kind of
method call into account.  Would you please raise it as an issue?

On Wed, May 19, 2010 at 4:18 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi all,
>
> I have noticed a little problem in the syntax hilighting with respect to
> objects we get from
> a getAt(..) method. Let me introduce an example:
>
>
> class
>
> A {
>
>     B getB() {
>
>         return new B()
>
>     }
>
>     B
>
> getAt(String s) {
>
>         return new B()
>
>     }
>
> }
>
>
>
> class
>
> B {
>
>     void sayHi() {
>
>         println "hi"
>
>     }
>
> }
>
>
>
> A a =
>
> new A()
>
>
>
> def
>
> b1 = a.getB() // (a)
>
> b1.sayHi()
>
>
>
> def
>
> b2 = a["foo"] // (b)
>
> b2.sayHi()
>
>
>
> B b3 = a[
>
> "bar"] // (c)
>
> b3.sayHi()
>
>
>
> What we can see is:
>
> - The class A defines two methods returning an object B
>
> - When calling getB() on line (a), the return type is correctly inferred and
> the call to sayHi() on the next line is not underlined
>
> - When calling the getAt method using the square bracket notation (line (b)
> and (c)), the returned type is messed up and the following lines show a call
> to sayHi() being not recognized (hence underlined)
>
> - Even in the case of line (c), when we statically declare b3, the call to
> sayHi() is not correctly recognized
>
> - The code completion is also not working properly. While it thinks b1 is of
> type B (suggesting the method sayHi), it thinks that b2 and b3 are of type A
> (suggesting the methods getB).
>
>
>
> Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira
> ticket?
>
>
>
> Thanks in advance.
>
> Cheers,
>
>
>
> Patrick
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Jayet, Patrick

Hi Andrew,

Thanks for your mail. New bug filed:
http://jira.codehaus.org/browse/GRECLIPSE-742

I have also noticed the following things re syntax hilighting. This time related to the type of an item, when extracted from a list, where the list item type is specified using Generics.

 

Here is an example:

class T {

    List<U> getUs() {

        return [new U()]

    }

}

class U {

    void sayHi() {

        println "hi"

    }

}

 

T t = new T()

List<U> coll = t.getUs()

 

def u1 = coll.get(0)

u1.sayHi() // (a) underlined

 

def u2 = coll.iterator().next()

u2.sayHi() // (b) underlined

 

U u3 = coll.iterator().next()

u3.sayHi() // (c) ok

 

coll.each {

    u4 -> u4.sayHi() // (d) underlined

}

 

coll.each {

    U u4 -> u4.sayHi() // (e) ok

}

 

We see that:

- Lines (c) and (e) are OK, since we explicitely define the item type

- Lines (a), (b) and (d) show the sayHi method being underlined, since the item type is not correctly inferred from the list type

 

Is this a bug? Is the inferrence engine supposed, in such a case, to get the item type right?

 

Thanks in advance.

Cheers,

 

Patrick



________________________________________
Von: [hidden email] [[hidden email]] im Auftrag von Andrew Eisenberg [[hidden email]]
Gesendet: Mittwoch, 19. Mai 2010 18:02
An: [hidden email]
Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Hi,

This is a bug.  The inferencing engine does not take this kind of
method call into account.  Would you please raise it as an issue?

On Wed, May 19, 2010 at 4:18 AM, Jayet, Patrick <[hidden email]> wrote:
> Hi all,
>
> I have noticed a little problem in the syntax hilighting with respect to
> objects we get from
> a getAt(..) method. Let me introduce an example:
>
>
> class
>
> A {
>
>     B getB() {
>
>         return new B()
>
>     }
>
>     B
>
> getAt(String s) {
>
>         return new B()
>
>     }
>
> }
>
>
>
> class
>
> B {
>
>     void sayHi() {
>
>         println "hi"
>
>     }
>
> }
>
>
>
> A a =
>
> new A()
>
>
>
> def
>
> b1 = a.getB() // (a)
>
> b1.sayHi()
>
>
>
> def
>
> b2 = a["foo"] // (b)
>
> b2.sayHi()
>
>
>
> B b3 = a[
>
> "bar"] // (c)
>
> b3.sayHi()
>
>
>
> What we can see is:
>
> - The class A defines two methods returning an object B
>
> - When calling getB() on line (a), the return type is correctly inferred and
> the call to sayHi() on the next line is not underlined
>
> - When calling the getAt method using the square bracket notation (line (b)
> and (c)), the returned type is messed up and the following lines show a call
> to sayHi() being not recognized (hence underlined)
>
> - Even in the case of line (c), when we statically declare b3, the call to
> sayHi() is not correctly recognized
>
> - The code completion is also not working properly. While it thinks b1 is of
> type B (suggesting the method sayHi), it thinks that b2 and b3 are of type A
> (suggesting the methods getB).
>
>
>
> Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira
> ticket?
>
>
>
> Thanks in advance.
>
> Cheers,
>
>
>
> Patrick
>
>

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: syntax hilighting strangeness

Andrew Eisenberg
Hi,

Again, you are pushing the limits of what is implemented in the
inferencing engine.  It does not look at generic types of lists to
determine the types of elements returned from the list.  Could you
raise another enhancement request for that?

On Fri, May 21, 2010 at 2:05 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi Andrew,
>
> Thanks for your mail. New bug filed:
> http://jira.codehaus.org/browse/GRECLIPSE-742
>
> I have also noticed the following things re syntax hilighting. This time
> related to the type of an item, when extracted from a list, where the list
> item type is specified using Generics.
>
>
>
> Here is an example:
>
> class
>
> T {
>
>     List<U> getUs() {
>
>         return [new U()]
>
>     }
>
> }
>
> class
>
> U {
>
>     void sayHi() {
>
>         println "hi"
>
>     }
>
> }
>
>
>
> T t =
>
> new T()
>
> List<U> coll = t.getUs()
>
>
>
> def
>
> u1 = coll.get(0)
>
> u1.sayHi()
>
> // (a) underlined
>
>
>
> def
>
> u2 = coll.iterator().next()
>
> u2.sayHi()
>
> // (b) underlined
>
>
>
> U u3 = coll.iterator().
>
> next()
>
> u3.sayHi()
>
> // (c) ok
>
>
>
> coll.
>
> each {
>
>     u4 -> u4.sayHi()
>
> // (d) underlined
>
> }
>
>
>
> coll.
>
> each {
>
>     U u4 -> u4.sayHi()
>
> // (e) ok
>
> }
>
>
>
> We see that:
>
> - Lines (c) and (e) are OK, since we explicitely define the item type
>
> - Lines (a), (b) and (d) show the sayHi method being underlined, since the
> item type is not correctly inferred from the list type
>
>
>
> Is this a bug? Is the inferrence engine supposed, in such a case, to get the
> item type right?
>
>
>
> Thanks in advance.
>
> Cheers,
>
>
>
> Patrick
>
> ________________________________________
> Von: [hidden email] [[hidden email]] im Auftrag von
> Andrew Eisenberg [[hidden email]]
> Gesendet: Mittwoch, 19. Mai 2010 18:02
> An: [hidden email]
> Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness
>
> Hi,
>
> This is a bug.  The inferencing engine does not take this kind of
> method call into account.  Would you please raise it as an issue?
>
> On Wed, May 19, 2010 at 4:18 AM, Jayet, Patrick <[hidden email]> wrote:
>> Hi all,
>>
>> I have noticed a little problem in the syntax hilighting with respect to
>> objects we get from
>> a getAt(..) method. Let me introduce an example:
>>
>>
>> class
>>
>> A {
>>
>>     B getB() {
>>
>>         return new B()
>>
>>     }
>>
>>     B
>>
>> getAt(String s) {
>>
>>         return new B()
>>
>>     }
>>
>> }
>>
>>
>>
>> class
>>
>> B {
>>
>>     void sayHi() {
>>
>>         println "hi"
>>
>>     }
>>
>> }
>>
>>
>>
>> A a =
>>
>> new A()
>>
>>
>>
>> def
>>
>> b1 = a.getB() // (a)
>>
>> b1.sayHi()
>>
>>
>>
>> def
>>
>> b2 = a["foo"] // (b)
>>
>> b2.sayHi()
>>
>>
>>
>> B b3 = a[
>>
>> "bar"] // (c)
>>
>> b3.sayHi()
>>
>>
>>
>> What we can see is:
>>
>> - The class A defines two methods returning an object B
>>
>> - When calling getB() on line (a), the return type is correctly inferred
>> and
>> the call to sayHi() on the next line is not underlined
>>
>> - When calling the getAt method using the square bracket notation (line
>> (b)
>> and (c)), the returned type is messed up and the following lines show a
>> call
>> to sayHi() being not recognized (hence underlined)
>>
>> - Even in the case of line (c), when we statically declare b3, the call to
>> sayHi() is not correctly recognized
>>
>> - The code completion is also not working properly. While it thinks b1 is
>> of
>> type B (suggesting the method sayHi), it thinks that b2 and b3 are of type
>> A
>> (suggesting the methods getB).
>>
>>
>>
>> Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira
>> ticket?
>>
>>
>>
>> Thanks in advance.
>>
>> Cheers,
>>
>>
>>
>> Patrick
>>
>>
>
> ---------------------------------------------------------------------
> 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
|

AW: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Jayet, Patrick
Hi Andrew,

Thank you for your mail.

Here is the bug report:
http://jira.codehaus.org/browse/GRECLIPSE-750

Cheers,
Patrick

________________________________________
Von: [hidden email] [[hidden email]] im Auftrag von Andrew Eisenberg [[hidden email]]
Gesendet: Freitag, 21. Mai 2010 18:01
An: [hidden email]
Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Hi,

Again, you are pushing the limits of what is implemented in the
inferencing engine.  It does not look at generic types of lists to
determine the types of elements returned from the list.  Could you
raise another enhancement request for that?

On Fri, May 21, 2010 at 2:05 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi Andrew,
>
> Thanks for your mail. New bug filed:
> http://jira.codehaus.org/browse/GRECLIPSE-742
>
> I have also noticed the following things re syntax hilighting. This time
> related to the type of an item, when extracted from a list, where the list
> item type is specified using Generics.
>
>
>
> Here is an example:
>
> class
>
> T {
>
>     List<U> getUs() {
>
>         return [new U()]
>
>     }
>
> }
>
> class
>
> U {
>
>     void sayHi() {
>
>         println "hi"
>
>     }
>
> }
>
>
>
> T t =
>
> new T()
>
> List<U> coll = t.getUs()
>
>
>
> def
>
> u1 = coll.get(0)
>
> u1.sayHi()
>
> // (a) underlined
>
>
>
> def
>
> u2 = coll.iterator().next()
>
> u2.sayHi()
>
> // (b) underlined
>
>
>
> U u3 = coll.iterator().
>
> next()
>
> u3.sayHi()
>
> // (c) ok
>
>
>
> coll.
>
> each {
>
>     u4 -> u4.sayHi()
>
> // (d) underlined
>
> }
>
>
>
> coll.
>
> each {
>
>     U u4 -> u4.sayHi()
>
> // (e) ok
>
> }
>
>
>
> We see that:
>
> - Lines (c) and (e) are OK, since we explicitely define the item type
>
> - Lines (a), (b) and (d) show the sayHi method being underlined, since the
> item type is not correctly inferred from the list type
>
>
>
> Is this a bug? Is the inferrence engine supposed, in such a case, to get the
> item type right?
>
>
>
> Thanks in advance.
>
> Cheers,
>
>
>
> Patrick
>
> ________________________________________
> Von: [hidden email] [[hidden email]] im Auftrag von
> Andrew Eisenberg [[hidden email]]
> Gesendet: Mittwoch, 19. Mai 2010 18:02
> An: [hidden email]
> Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness
>
> Hi,
>
> This is a bug.  The inferencing engine does not take this kind of
> method call into account.  Would you please raise it as an issue?
>
> On Wed, May 19, 2010 at 4:18 AM, Jayet, Patrick <[hidden email]> wrote:
>> Hi all,
>>
>> I have noticed a little problem in the syntax hilighting with respect to
>> objects we get from
>> a getAt(..) method. Let me introduce an example:
>>
>>
>> class
>>
>> A {
>>
>>     B getB() {
>>
>>         return new B()
>>
>>     }
>>
>>     B
>>
>> getAt(String s) {
>>
>>         return new B()
>>
>>     }
>>
>> }
>>
>>
>>
>> class
>>
>> B {
>>
>>     void sayHi() {
>>
>>         println "hi"
>>
>>     }
>>
>> }
>>
>>
>>
>> A a =
>>
>> new A()
>>
>>
>>
>> def
>>
>> b1 = a.getB() // (a)
>>
>> b1.sayHi()
>>
>>
>>
>> def
>>
>> b2 = a["foo"] // (b)
>>
>> b2.sayHi()
>>
>>
>>
>> B b3 = a[
>>
>> "bar"] // (c)
>>
>> b3.sayHi()
>>
>>
>>
>> What we can see is:
>>
>> - The class A defines two methods returning an object B
>>
>> - When calling getB() on line (a), the return type is correctly inferred
>> and
>> the call to sayHi() on the next line is not underlined
>>
>> - When calling the getAt method using the square bracket notation (line
>> (b)
>> and (c)), the returned type is messed up and the following lines show a
>> call
>> to sayHi() being not recognized (hence underlined)
>>
>> - Even in the case of line (c), when we statically declare b3, the call to
>> sayHi() is not correctly recognized
>>
>> - The code completion is also not working properly. While it thinks b1 is
>> of
>> type B (suggesting the method sayHi), it thinks that b2 and b3 are of type
>> A
>> (suggesting the methods getB).
>>
>>
>>
>> Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira
>> ticket?
>>
>>
>>
>> Thanks in advance.
>>
>> Cheers,
>>
>>
>>
>> Patrick
>>
>>
>
> ---------------------------------------------------------------------
> 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
|

AW: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Jayet, Patrick
Hi Andrew,

I have noticed another small inconsistency in the syntax hilighting:

  def v1 = 1

  def v2 = v1 + 1

  def v3 = v1 / 2 // (A)

  println "$v1 $v2 $v3"


On line (A), the division sign and following 2 are pink and in italic. On the previous line, the '+ 1' are black and not in italic. Is this a bug?

 

Thanks in advance.

Cheers,

 

Patrick


________________________________________
Von: Jayet, Patrick [[hidden email]]
Gesendet: Dienstag, 25. Mai 2010 14:14
An: [hidden email]
Betreff: AW: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Hi Andrew,

Thank you for your mail.

Here is the bug report:
http://jira.codehaus.org/browse/GRECLIPSE-750

Cheers,
Patrick

________________________________________
Von: [hidden email] [[hidden email]] im Auftrag von Andrew Eisenberg [[hidden email]]
Gesendet: Freitag, 21. Mai 2010 18:01
An: [hidden email]
Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness

Hi,

Again, you are pushing the limits of what is implemented in the
inferencing engine.  It does not look at generic types of lists to
determine the types of elements returned from the list.  Could you
raise another enhancement request for that?

On Fri, May 21, 2010 at 2:05 AM, Jayet, Patrick <[hidden email]> wrote:
> Hi Andrew,
>
> Thanks for your mail. New bug filed:
> http://jira.codehaus.org/browse/GRECLIPSE-742
>
> I have also noticed the following things re syntax hilighting. This time
> related to the type of an item, when extracted from a list, where the list
> item type is specified using Generics.
>
>
>
> Here is an example:
>
> class
>
> T {
>
>     List<U> getUs() {
>
>         return [new U()]
>
>     }
>
> }
>
> class
>
> U {
>
>     void sayHi() {
>
>         println "hi"
>
>     }
>
> }
>
>
>
> T t =
>
> new T()
>
> List<U> coll = t.getUs()
>
>
>
> def
>
> u1 = coll.get(0)
>
> u1.sayHi()
>
> // (a) underlined
>
>
>
> def
>
> u2 = coll.iterator().next()
>
> u2.sayHi()
>
> // (b) underlined
>
>
>
> U u3 = coll.iterator().
>
> next()
>
> u3.sayHi()
>
> // (c) ok
>
>
>
> coll.
>
> each {
>
>     u4 -> u4.sayHi()
>
> // (d) underlined
>
> }
>
>
>
> coll.
>
> each {
>
>     U u4 -> u4.sayHi()
>
> // (e) ok
>
> }
>
>
>
> We see that:
>
> - Lines (c) and (e) are OK, since we explicitely define the item type
>
> - Lines (a), (b) and (d) show the sayHi method being underlined, since the
> item type is not correctly inferred from the list type
>
>
>
> Is this a bug? Is the inferrence engine supposed, in such a case, to get the
> item type right?
>
>
>
> Thanks in advance.
>
> Cheers,
>
>
>
> Patrick
>
> ________________________________________
> Von: [hidden email] [[hidden email]] im Auftrag von
> Andrew Eisenberg [[hidden email]]
> Gesendet: Mittwoch, 19. Mai 2010 18:02
> An: [hidden email]
> Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness
>
> Hi,
>
> This is a bug.  The inferencing engine does not take this kind of
> method call into account.  Would you please raise it as an issue?
>
> On Wed, May 19, 2010 at 4:18 AM, Jayet, Patrick <[hidden email]> wrote:
>> Hi all,
>>
>> I have noticed a little problem in the syntax hilighting with respect to
>> objects we get from
>> a getAt(..) method. Let me introduce an example:
>>
>>
>> class
>>
>> A {
>>
>>     B getB() {
>>
>>         return new B()
>>
>>     }
>>
>>     B
>>
>> getAt(String s) {
>>
>>         return new B()
>>
>>     }
>>
>> }
>>
>>
>>
>> class
>>
>> B {
>>
>>     void sayHi() {
>>
>>         println "hi"
>>
>>     }
>>
>> }
>>
>>
>>
>> A a =
>>
>> new A()
>>
>>
>>
>> def
>>
>> b1 = a.getB() // (a)
>>
>> b1.sayHi()
>>
>>
>>
>> def
>>
>> b2 = a["foo"] // (b)
>>
>> b2.sayHi()
>>
>>
>>
>> B b3 = a[
>>
>> "bar"] // (c)
>>
>> b3.sayHi()
>>
>>
>>
>> What we can see is:
>>
>> - The class A defines two methods returning an object B
>>
>> - When calling getB() on line (a), the return type is correctly inferred
>> and
>> the call to sayHi() on the next line is not underlined
>>
>> - When calling the getAt method using the square bracket notation (line
>> (b)
>> and (c)), the returned type is messed up and the following lines show a
>> call
>> to sayHi() being not recognized (hence underlined)
>>
>> - Even in the case of line (c), when we statically declare b3, the call to
>> sayHi() is not correctly recognized
>>
>> - The code completion is also not working properly. While it thinks b1 is
>> of
>> type B (suggesting the method sayHi), it thinks that b2 and b3 are of type
>> A
>> (suggesting the methods getB).
>>
>>
>>
>> Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira
>> ticket?
>>
>>
>>
>> Thanks in advance.
>>
>> Cheers,
>>
>>
>>
>> Patrick
>>
>>
>
> ---------------------------------------------------------------------
> 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: syntax hilighting strangeness

Andrew Eisenberg
This is a known problem with slashy strings.

http://jira.codehaus.org/browse/GRECLIPSE-124

I have not had time to work on this, but if this is very annoying for
you, please vote/comment on the issue and I will have a go.

On Thu, May 27, 2010 at 1:35 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi Andrew,
>
> I have noticed another small inconsistency in the syntax hilighting:
>
>   def
>
> v1 = 1
>
>   def
>
> v2 = v1 + 1
>
>   def
>
> v3 = v1 / 2 // (A)
>
>   println
>
> "$v1 $v2 $v3"
>
> On line (A), the division sign and following 2 are pink and in italic. On
> the previous line, the '+ 1' are black and not in italic. Is this a bug?
>
>
>
> Thanks in advance.
>
> Cheers,
>
>
>
> Patrick
>
> ________________________________________
> Von: Jayet, Patrick [[hidden email]]
> Gesendet: Dienstag, 25. Mai 2010 14:14
>
> An: [hidden email]
> Betreff: AW: [groovy-eclipse-plugin-user] syntax hilighting strangeness
>
> Hi Andrew,
>
> Thank you for your mail.
>
> Here is the bug report:
> http://jira.codehaus.org/browse/GRECLIPSE-750
>
> Cheers,
> Patrick
>
> ________________________________________
> Von: [hidden email] [[hidden email]] im Auftrag von
> Andrew Eisenberg [[hidden email]]
> Gesendet: Freitag, 21. Mai 2010 18:01
> An: [hidden email]
> Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness
>
> Hi,
>
> Again, you are pushing the limits of what is implemented in the
> inferencing engine.  It does not look at generic types of lists to
> determine the types of elements returned from the list.  Could you
> raise another enhancement request for that?
>
> On Fri, May 21, 2010 at 2:05 AM, Jayet, Patrick <[hidden email]> wrote:
>> Hi Andrew,
>>
>> Thanks for your mail. New bug filed:
>> http://jira.codehaus.org/browse/GRECLIPSE-742
>>
>> I have also noticed the following things re syntax hilighting. This time
>> related to the type of an item, when extracted from a list, where the list
>> item type is specified using Generics.
>>
>>
>>
>> Here is an example:
>>
>> class
>>
>> T {
>>
>>     List<U> getUs() {
>>
>>         return [new U()]
>>
>>     }
>>
>> }
>>
>> class
>>
>> U {
>>
>>     void sayHi() {
>>
>>         println "hi"
>>
>>     }
>>
>> }
>>
>>
>>
>> T t =
>>
>> new T()
>>
>> List<U> coll = t.getUs()
>>
>>
>>
>> def
>>
>> u1 = coll.get(0)
>>
>> u1.sayHi()
>>
>> // (a) underlined
>>
>>
>>
>> def
>>
>> u2 = coll.iterator().next()
>>
>> u2.sayHi()
>>
>> // (b) underlined
>>
>>
>>
>> U u3 = coll.iterator().
>>
>> next()
>>
>> u3.sayHi()
>>
>> // (c) ok
>>
>>
>>
>> coll.
>>
>> each {
>>
>>     u4 -> u4.sayHi()
>>
>> // (d) underlined
>>
>> }
>>
>>
>>
>> coll.
>>
>> each {
>>
>>     U u4 -> u4.sayHi()
>>
>> // (e) ok
>>
>> }
>>
>>
>>
>> We see that:
>>
>> - Lines (c) and (e) are OK, since we explicitely define the item type
>>
>> - Lines (a), (b) and (d) show the sayHi method being underlined, since the
>> item type is not correctly inferred from the list type
>>
>>
>>
>> Is this a bug? Is the inferrence engine supposed, in such a case, to get
>> the
>> item type right?
>>
>>
>>
>> Thanks in advance.
>>
>> Cheers,
>>
>>
>>
>> Patrick
>>
>> ________________________________________
>> Von: [hidden email] [[hidden email]] im Auftrag
>> von
>> Andrew Eisenberg [[hidden email]]
>> Gesendet: Mittwoch, 19. Mai 2010 18:02
>> An: [hidden email]
>> Betreff: Re: [groovy-eclipse-plugin-user] syntax hilighting strangeness
>>
>> Hi,
>>
>> This is a bug.  The inferencing engine does not take this kind of
>> method call into account.  Would you please raise it as an issue?
>>
>> On Wed, May 19, 2010 at 4:18 AM, Jayet, Patrick <[hidden email]> wrote:
>>> Hi all,
>>>
>>> I have noticed a little problem in the syntax hilighting with respect to
>>> objects we get from
>>> a getAt(..) method. Let me introduce an example:
>>>
>>>
>>> class
>>>
>>> A {
>>>
>>>     B getB() {
>>>
>>>         return new B()
>>>
>>>     }
>>>
>>>     B
>>>
>>> getAt(String s) {
>>>
>>>         return new B()
>>>
>>>     }
>>>
>>> }
>>>
>>>
>>>
>>> class
>>>
>>> B {
>>>
>>>     void sayHi() {
>>>
>>>         println "hi"
>>>
>>>     }
>>>
>>> }
>>>
>>>
>>>
>>> A a =
>>>
>>> new A()
>>>
>>>
>>>
>>> def
>>>
>>> b1 = a.getB() // (a)
>>>
>>> b1.sayHi()
>>>
>>>
>>>
>>> def
>>>
>>> b2 = a["foo"] // (b)
>>>
>>> b2.sayHi()
>>>
>>>
>>>
>>> B b3 = a[
>>>
>>> "bar"] // (c)
>>>
>>> b3.sayHi()
>>>
>>>
>>>
>>> What we can see is:
>>>
>>> - The class A defines two methods returning an object B
>>>
>>> - When calling getB() on line (a), the return type is correctly inferred
>>> and
>>> the call to sayHi() on the next line is not underlined
>>>
>>> - When calling the getAt method using the square bracket notation (line
>>> (b)
>>> and (c)), the returned type is messed up and the following lines show a
>>> call
>>> to sayHi() being not recognized (hence underlined)
>>>
>>> - Even in the case of line (c), when we statically declare b3, the call
>>> to
>>> sayHi() is not correctly recognized
>>>
>>> - The code completion is also not working properly. While it thinks b1 is
>>> of
>>> type B (suggesting the method sayHi), it thinks that b2 and b3 are of
>>> type
>>> A
>>> (suggesting the methods getB).
>>>
>>>
>>>
>>> Is this a bug within the Groovy Eclipse plug-in? Should I file a Jira
>>> ticket?
>>>
>>>
>>>
>>> Thanks in advance.
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Patrick
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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