On Tue, 21 Jul 2020 at 17:05, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

So I need to subclass first, and then instantiate that new class?

The class you referred to is abstract, so yes you need a subclass to instantiate it, generics or not.

Can I to do that with the provided support? I've used jnew-runtime-class

jnew-runtime-class (class-name super-name interfaces constructors methods fields &optional filename)

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?

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.

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.

[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.

For JSS syntax I would probably just accept a list class argument to new.

(new '(InferredObjectPropertyAxiomGenerator OWLObjectSubPropertyAxiom) ...)

You don't supply those parameters with the constructor at all. When you write:

List<Foo> foos = new ArrayList<Foo>();

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 :)

Presumably keep a cache of the created subclasses indexed by that list.

It would be nice to be able to find by reflection that InferredObjectPropertyAxiomGenerator is a generic and how many class arguments there are.

Alan

On Tue, Jul 21, 2020 at 7:06 AM Alessio Stalla <alessiostalla@gmail.com> wrote:
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.
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.

On Mon, 20 Jul 2020 at 18:49, Mark Evenson <evenson@panix.com> wrote:

> On Jul 16, 2020, at 04:30, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>
> For instance in
>
> http://owlcs.github.io/owlapi/apidocs_4/org/semanticweb/owlapi/util/InferredObjectPropertyAxiomGenerator.html
>
> It says:
> Type Parameters:
> A - the axiom type
> Question is: how do I supply the axiom type when creating an instance.

Can you point me to some code that does the setup? Somewhere in lsw2?

Alessio is correct that the compiler erases types, but I have sucessfully
created instances that switch such methods over the years working on reasoners,
so I should be able to get this to work for you. Unfortunately the margin is
too small to contain a proof of this statement without further annotation…

--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."