[forge-dev] in forge java model, are two different implementations of the same java class equal?

[Lincoln Baxter, III]

Would it be too naive to simply take the fully qualified name and compare
that? I understand that there may be different method signatures in the
API, but...

If we really wanted to, we could compare the public signature of the class
and determine non-generic equivalence. Thoughts?


On Sat, Feb 23, 2013 at 4:17 PM, John Franey <jjfraney at gmail.com> wrote:

> But: Equality test is not going to work in all cases. Not all information
> from the source is compiled into the class file by the java compiler.  For
> example, erasure (generics) and SOURCE and CLASS RetentionPolicy on
> annotations.
>
>
>
>
> On Sat, Feb 23, 2013 at 3:07 PM, John Franey <jjfraney at gmail.com> wrote:
>
>> I agree.  Here is the impact on the implementation.
>>
>> First, equals/hashcode cannot depend on internals of their class, instead
>> they must be implemented in terms of the public methods of the java model
>> interface.  JavaClassImplOne and JavaClassImplTwo would have different
>> internal variables.
>>
>> Second, equals cannot fail if the compared objects are not the same
>> class, e.g. JavaClassImplOne and JavaClassImplTwo.  e.g., use
>> other.isAssignable(JavaClass.class).
>>
>> Third, equals/hashcode implementations that depend only on the methods of
>> the java model api would probably not belong in the impl package.  They
>> would probably be better located in the api package.   Then
>> JavaClassImplTwo would not have to depend on impl.JavaClass to share
>> equals/hashcode.  This would mean that some interfaces in api package would
>> have to be abstract classes.
>>
>> Others?
>>
>> Thoughts?
>>
>> Regards,
>> John
>>
>>
>> On Sat, Feb 23, 2013 at 1:45 PM, George Gastaldi <ggastald at redhat.com>wrote:
>>
>>> IMHO, equals should return true in this case only if the class structure
>>> (including attributes, interfaces, methods) matches. The fact that a class
>>> is editable or not shouldn't matter in terms of comparison.
>>>
>>> Em 23/02/2013, às 15:38, John Franey <jjfraney at gmail.com> escreveu:
>>>
>>> >
>>> > This is with respect to providing an alternate java model
>>> implementation for binary classes defined in other projects.
>>> >
>>> > Given two JavaClass with exactly the same java definition, but one
>>> comes from source code, and the other from a binary class file, (or in
>>> other terms, one is editable, the other is not), would
>>> (javaClass1.equals(javaClass2) == true)?
>>> >
>>> > It likely does not matter in practice.  The likelihood of a forge
>>> developer creating as source class with a definition exactly like a binary
>>> dependency seems very low, not impossible, but low.
>>> >
>>> >
>>> >
>>> > John
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > forge-dev mailing list
>>> > forge-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130226/2b72dc54/attachment.html