Alexander Veit | 9 Aug 00:34

[groovy-dev] How to reopen a JIRA issue?

Hi,

can anybody help me reopening a JIRA issue? I've either not a clue or no
rights to do so.

http://jira.codehaus.org/browse/GROOVY-626

Thank you very much,
Alex

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

    http://xircles.codehaus.org/manage_email

Jochen Theodorou | 9 Aug 16:41
Gravatar

Re: [groovy-dev] How to reopen a JIRA issue?

Alexander Veit schrieb:
> Hi,
> 
> can anybody help me reopening a JIRA issue? I've either not a clue or no
> rights to do so.
> 
> http://jira.codehaus.org/browse/GROOVY-626

not sure everyone can reopen an issue... any despot can of course, the 
issue reporter can too, maybe the assignee also.

As for the bug... there are other bugs more suitable for this, they are 
open and targeted for 2.0. Atm it is on purpose that "${2}" == "2", 
because we want to have that. hashcode should not be equal, because a 
GString is not a String...

maybe I should explain that a little bit more... when you do in java 
1==1l then you get true, even though 1 is an int and 1l is a long. Now 
new Integer(1)==new Long(1) won't obviously work. Also 
Integer(1).equals(new Long(1)) won't do. In Groovy we don't have the 
different level of the primitive. 1 is not int, but Integer, so 1l is 
Long. But we still want 1==1l to be true, without touching equals. As a 
result == can not be the same as equals.

And while we have this for primitive numbers in Java, and for object 
numbers in Groovy, we also have that for String and GString in Groovy.

bye blackdrag

--

-- 
(Continue reading)

Alexander Veit | 9 Aug 17:59

RE: [groovy-dev] How to reopen a JIRA issue?

Hi Jochen, 

> Jochen Theodorou wrote:
> Alexander Veit schrieb:
> > Hi,
> > 
> > can anybody help me reopening a JIRA issue? I've either not 
> a clue or no
> > rights to do so.
> > 
> > http://jira.codehaus.org/browse/GROOVY-626
> 
> not sure everyone can reopen an issue... any despot can of 
> course, the 
> issue reporter can too, maybe the assignee also.
> 
> As for the bug... there are other bugs more suitable for 
> this, they are 
> open and targeted for 2.0. Atm it is on purpose that "${2}" == "2", 
> because we want to have that. hashcode should not be equal, because a 
> GString is not a String...
> 
> maybe I should explain that a little bit more... when you do in java 
> 1==1l then you get true, even though 1 is an int and 1l is a 
> long.
> Now  new Integer(1)==new Long(1) won't obviously work. Also 
> Integer(1).equals(new Long(1)) won't do. In Groovy we don't have the 
> different level of the primitive. 1 is not int, but Integer, so 1l is 
> Long. But we still want 1==1l to be true, without touching 
> equals. As a result == can not be the same as equals.
(Continue reading)

Martin C. Martin | 9 Aug 18:09

Re: [groovy-dev] How to reopen a JIRA issue?


Jochen Theodorou wrote:
>  As a result == can not be the same as equals.
> 
> And while we have this for primitive numbers in Java, and for object 
> numbers in Groovy, we also have that for String and GString in Groovy.

We use Java hash tables for our hash tables, which use equals(), so it's 
possible to insert something in a hash table using a key, then try to 
find it using a key that's == to it and not find it.  e.g. if you insert 
with Integer(1) as the key and look up with Long(1) as the key.

It might be worthwhile having a kind of hash table that uses == as its 
equality, but you'd have to figure out some way for the user to supply 
hash functions, which could be a little messy.  And in practice, the 
"different but ==" hash table problem doesn't come up much.

Best,
Martin

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

    http://xircles.codehaus.org/manage_email


Gmane