Tom Tromey <[EMAIL PROTECTED]> writes:
> > "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
>
> Brian> These have not been applied yet, we should do so before Friday.
> Brian> Does this look okay to everyone?
>
> Yes, except for one little nit:
>
> >> - // Implementation note:
> >> -
These have not been applied yet, we should do so before Friday. Does
this look okay to everyone?
Brian
Archie Cobbs <[EMAIL PROTECTED]> writes:
> Archie Cobbs wrote:
> > The practical upshot of this is that the equals() methods that currently
> > exist in Classpath for Field and Constructor nee
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
Brian> These have not been applied yet, we should do so before Friday.
Brian> Does this look okay to everyone?
Yes, except for one little nit:
>> - // Implementation note:
>> - // The following is a correct but possibly slow impl
On Mon, 3 Mar 2003, Archie Cobbs wrote:
> Chris Gray wrote:
> >>>I'm assuming here that the VM guarantees that only one Method object
> >>>will ever be created for each declared method in a class.
No I didn't.
> >>I used to think that this would be the optimal thing todo for a VM. [...]
Nor tha
Hi,
On Mon, 2003-03-03 at 19:45, Archie Cobbs wrote:
> So, let me try to summarize this thread (to confirm my own understanding).
>
> #1 Because Method, Field, and Constructor are mutable objects, every
> method that returns a Method, Field, or Constructor object should
> instantiate a ne
Archie Cobbs wrote:
> The practical upshot of this is that the equals() methods that currently
> exist in Classpath for Field and Constructor need to be fixed. But the
> fixes could use "obj1.getDeclaringClass() == obj2.getDeclaringClass()"
> as part of the test.
>
> Method also needs to be fixed,
Chris Gray wrote:
I'm assuming here that the VM guarantees that only one Method object
will ever be created for each declared method in a class.
I used to think that this would be the optimal thing todo for a VM. But
in reality each Method object returned should actually be unique. The
reason is th
On 1 Mar 2003, Mark Wielaard wrote:
> Hi,
>
> On Fri, 2003-02-28 at 21:58, Archie Cobbs wrote:
> > I'm assuming here that the VM guarantees that only one Method object
> > will ever be created for each declared method in a class.
>
> I used to think that this would be the optimal thing todo for
Hi,
On Sat, 2003-03-01 at 17:05, Dalibor Topic wrote:
> > (Note that in contrast each
> > Class object should
> > have the property they are unique.)
>
> Unique in the context of the class loader, or unique
> for all class loaders? I think they have to be unique
> in the context of their class lo
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
> As a consequence some of the reflect classes have to
> be carefully
> examined to make sure that they do not make the
> assumption that equals
> means same reference. (Note that in contrast each
> Class object should
> have the property they are uniq
Hi,
On Fri, 2003-02-28 at 21:58, Archie Cobbs wrote:
> I'm assuming here that the VM guarantees that only one Method object
> will ever be created for each declared method in a class.
I used to think that this would be the optimal thing todo for a VM. But
in reality each Method object returned sh
Per Bothner wrote:
I'm assuming here that the VM guarantees that only one Method object
will ever be created for each declared method in a class.
Why are you assuming this? It is possible the VM internal
data structures are unrelated to java.lang.reflect.Method,
and so it may make sense to create
Archie Cobbs wrote:
I'm assuming here that the VM guarantees that only one Method object
will ever be created for each declared method in a class.
Why are you assuming this? It is possible the VM internal
data structures are unrelated to java.lang.reflect.Method,
and so it may make sense to create
Tom Tromey wrote:
> Archie> - [ lots of code ]
> Archie> + return this == o;
> Archie>}
>
> I don't think there's a guarantee that every call to Class will return
> an identical Method. You have to look at the fields somehow.
If two different Method objects are equal according to the
> "Archie" == Archie Cobbs <[EMAIL PROTECTED]> writes:
Archie> - [ lots of code ]
Archie> + return this == o;
Archie>}
I don't think there's a guarantee that every call to Class will return
an identical Method. You have to look at the fields somehow.
Tom
___
Tom Tromey wrote:
> Archie> Howver, this contradicts the JDK 1.4 docs, which say that the
> Archie> method's return type must also be equal:
>
> Archie> Is this a classpath bug?
>
> Yes. Care to submit a patch?
Sure! See below... fortunately this vastly simplifies things :-)
> Maybe this chang
Archie Cobbs <[EMAIL PROTECTED]> writes:
> Howver, this contradicts the JDK 1.4 docs, which say that the method's
> return type must also be equal:
>
>
> http://java.sun.com/j2se/1.4/docs/api/java/lang/reflect/Method.html#equals(java.lang.Object)
>
> Is this a classpath bug?
I looked... I
> "Archie" == Archie Cobbs <[EMAIL PROTECTED]> writes:
Archie> Howver, this contradicts the JDK 1.4 docs, which say that the
Archie> method's return type must also be equal:
Archie> Is this a classpath bug?
Yes. Care to submit a patch?
Maybe this changed from 1.3 to 1.4. I know a lot of c
Hi,
In classpath-0.05, Method.equals() is described this way:
/**
* Compare two objects to see if they are semantically equivalent.
* Two Methods are semantically equivalent if they have the same declaring
* class, name, and parameter list. This ignores different exception
* clause
19 matches
Mail list logo
