<div dir="ltr">Yeah, I think I like that approach. Just mirror what ClassLoaders do.<br><br>+1<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 27, 2013 at 2:12 AM, Thomas Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>perhaps something similar to class
loading makes sense: origin of class (jar/file system) + qualified
name<br>
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<br>
<br>
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?<br>
<br>
<br>
Am <a href="tel:26.02.2013%2023" value="+12602201323" target="_blank">26.02.2013 23</a>:18, schrieb Lincoln Baxter, III:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">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...<br>
<br>
If we really wanted to, we could compare the public signature of
the class and determine non-generic equivalence. Thoughts?<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Feb 23, 2013 at 4:17 PM, John
Franey <span dir="ltr"><<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div>
<br>
</div>
<div><br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Feb 23, 2013 at 3:07
PM, John Franey <span dir="ltr"><<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I agree. Here is the impact on the
implementation.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Others?</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>Regards,</div>
<div>John</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Sat, Feb 23, 2013 at 1:45 PM, George
Gastaldi <span dir="ltr"><<a href="mailto:ggastald@redhat.com" target="_blank">ggastald@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Em 23/02/2013, às 15:38, John Franey
<<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>>
escreveu:<br>
<div>
<div><br>
><br>
> This is with respect to
providing an alternate java model
implementation for binary classes
defined in other projects.<br>
><br>
> 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)?<br>
><br>
> 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.<br>
><br>
><br>
><br>
> John<br>
><br>
><br>
><br>
</div>
</div>
>
_______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>