Hi,

I uploaded a patch that now also uses the rank function for constructors as
well as a testcase.

I need to think a bit on the Interface stuff and how this matches the class
tests. A java class implements a specific set of interfaces I think, so in
the "class" hierarchy we don't need to consider this or? An extract of
generated code in the selection for the test case:

switch (PyTuple_GET_SIZE(args)) {
 case 1:
  {
    ::org::jcc::test::Cat a0((jobject) NULL);
    ::org::jcc::test::Cat result((jobject) NULL);

    if (!parseArgs(args, "k", ::org::jcc::test::Cat::initializeClass, &a0))
    {
      OBJ_CALL(result = self->object.getNewOne(a0));
      return ::org::jcc::test::t_Cat::wrap_Object(result);
    }
  }
  {
    ::org::jcc::test::Feline a0((jobject) NULL);
    ::org::jcc::test::Feline result((jobject) NULL);

    if (!parseArgs(args, "k", ::org::jcc::test::Feline::initializeClass, &a0))
    {
      OBJ_CALL(result = self->object.getNewOne(a0));
      return ::org::jcc::test::t_Feline::wrap_Object(result);
    }
  }

So itn that case it will matter how the parseArgs function matches, but
methods that are implemented as part of an interface would be handled just
like any method I assume?

But Interfaces themselves are possible to "wrap" as well I think? Maybe
this is where this is needed for pure interface hierarchies?

I will spend some more thinking on this, not a java expert..

Regards
/Petrus


On Thu, Apr 18, 2019 at 8:00 PM Andi Vajda (JIRA) <j...@apache.org> wrote:

>
>     [
> https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821358#comment-16821358
> ]
>
> Andi Vajda commented on PYLUCENE-47:
> ------------------------------------
>
>
>
> In that case, my comment makes no sense, sorry for the noise.
>
>
> Not in terms of isAssignableFrom() but in terms of how many interfaces a
> parameter class implements (in essence, the interface hierarchy is a
> parallel class hierarchy, with multiple super-interfaces allowed).
> Counting
> those may give us some signal as to how deep a parameter class is and help
> with sorting.
>
>
> Yes, we have the same bug there.
>
> Andi..
>
>
> > Type matching in methods with same number of arguments
> > ------------------------------------------------------
> >
> >                 Key: PYLUCENE-47
> >                 URL: https://issues.apache.org/jira/browse/PYLUCENE-47
> >             Project: PyLucene
> >          Issue Type: Bug
> >            Reporter: Petrus Hyvönen
> >            Priority: Major
> >         Attachments: java-example-test-parameters-v2.2.zip,
> java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch
> >
> >
> > If the same number of arguments are used in a method and the arguments
> are positively matched also on subclasses of the argument. The order of
> testing in the generated code will matter and give unpredictable results.
> > A test case is attached below. It should fail in most cases but with a
> piece of luck the order of tests in the generated code may get right and it
> will work (1/24 chance if at random).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>


-- 
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00

Reply via email to