<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Jul 2020 at 17:05, Alan Ruttenberg <<a href="mailto:alanruttenberg@gmail.com">alanruttenberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>So I need to subclass first, and then instantiate that new class?</div></div></blockquote><div><br></div><div>The class you referred to is abstract, so yes you need a subclass to instantiate it, generics or not.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> Can I to do that with the provided support? I've used jnew-runtime-class</div><div><br></div><div><span>jnew-runtime-class</span> (class-name super-name interfaces constructors methods fields &optional filename)</div><div><br></div><div>Not sure how I would provide the specializing class(es) here. The type information may be "erased" but methods can still differ by specialization, right?<br></div></div></blockquote><div><br></div><div>If there's no specializers argument, then I'm afraid you cannot provide them. However, the type specializer is only useful if the class or framework does some advanced reflection magic at runtime to read it [1]. You don't need it in general in Lisp or dynamic Java (with reflection), the type being erased means that methods all take/return Object (or the most specific supertype available, in general) and do no runtime checks.</div><div>If you had written your class in Java, then the Java compiler would have inserted synthetic methods with the more specific signature, and it would have inserted type casts at call sites. But this is just an aid towards type safety. Java generics are designed so as to be compatible with the pre-generics world: you can happily omit them and the compiler will only issue some type safety warnings. Unless, as I said, the library or framework does some fancy reflection thing to inspect the generic type parameters of subclasses, and doesn't account for users not specifying such parameters.<br></div><div><br></div><div>[1] or if the class is to be used by a tool doing static analysis, e.g. an IDE or the Java compiler, and you want to restrict its usage to only the provided type, but I guess it's not your case.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>For JSS syntax I would probably just accept a list class argument to new.<br></div><div><br></div><div>(new '(InferredObjectPropertyAxiomGenerator OWLObjectSubPropertyAxiom) ...)</div></div></blockquote><div><br></div><div>You don't supply those parameters with the constructor at all. When you write:</div><div>List<Foo> foos = new ArrayList<Foo>();</div><div>The information about Foo only exists in the compiler's head. There's no trace of it whatsoever at runtime. That's why it's called erasure :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Presumably keep a cache of the created subclasses indexed by that list.</div><div> <br></div><div>It would be nice to be able to find by reflection that InferredObjectPropertyAxiomGenerator is a generic and how many class arguments there are.</div><div><br></div><div>Alan<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 7:06 AM Alessio Stalla <<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Oh, the class is abstract, so you're meant to provide A by subclassing it, not by instantiating. In that case, the value of A *is* retained at runtime and is available for reflection, even if method signatures are still erased to Object.</div><div>In ABCL there used to be some runtime-class machinery that was just a sketch... I don't know if it's still there and has enough plumbing to allow you to subclass a generic class providing type specifiers.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 20 Jul 2020 at 18:49, Mark Evenson <<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jul 16, 2020, at 04:30, Alan Ruttenberg <<a href="mailto:alanruttenberg@gmail.com" target="_blank">alanruttenberg@gmail.com</a>> wrote:<br>
> <br>
> For instance in <br>
> <br>
> <a href="http://owlcs.github.io/owlapi/apidocs_4/org/semanticweb/owlapi/util/InferredObjectPropertyAxiomGenerator.html" rel="noreferrer" target="_blank">http://owlcs.github.io/owlapi/apidocs_4/org/semanticweb/owlapi/util/InferredObjectPropertyAxiomGenerator.html</a><br>
> <br>
> It says:<br>
> Type Parameters:<br>
> A - the axiom type<br>
> Question is: how do I supply the axiom type when creating an instance.<br>
<br>
Can you point me to some code that does the setup?  Somewhere in lsw2?<br>
<br>
Alessio is correct that the compiler erases types, but I have sucessfully<br>
created instances that switch such methods over the years working on reasoners,<br>
so I should be able to get this to work for you.  Unfortunately the margin is<br>
too small to contain a proof of this statement without further annotation…<br>
<br>
-- <br>
"A screaming comes across the sky.  It has happened before but there is nothing <br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>