8:12 a.m.
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
<mailto:jjfraney@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(a)gmail.com
<mailto:jjfraney@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(a)redhat.com <mailto:ggastald@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(a)gmail.com
<mailto:jjfraney@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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org <mailto:forge-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev