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(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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(a)gmail.com&gt; 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(a)redhat.com&gt;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(a)gmail.com&gt; 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/forge-dev >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt;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(a)gmail.com&gt; 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(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/forge-dev >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev