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

[Thomas Frühbeck]

perhaps something similar to class loading makes sense: origin of class 
(jar/file system) + qualified name
IMHO: origin matters for the plugin (e.g. scaffold), qualified name 
matters for the generated application, I can't see a way to handle such 
completely different view in a consistent simple way

I would stay away from anything more "intelligent" than is possible, 
equivalence of method signature is merely another - perhaps unwanted - 
coincidence, if the runtime provides more than one class per qualified 
name which are not _really_ equal, isn't it?


Am 26.02.2013 23:18, schrieb 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 
> <mailto: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
>     <mailto: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 <mailto: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
>             <mailto: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 <mailto:forge-dev at lists.jboss.org>
>             > https://lists.jboss.org/mailman/listinfo/forge-dev
>
>             _______________________________________________
>             forge-dev mailing list
>             forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
>     _______________________________________________
>     forge-dev mailing list
>     forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130227/c09f3836/attachment-0001.html