[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
Re: [jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
On Wed, 17 Apr 2019, Petrus Hyvönen (JIRA) wrote: Petrus Hyvönen commented on PYLUCENE-47: Thanks for looking at this. I am not sure I understand your comments/questions. I don't think it is possible to have method overloading based on return type, so not sure what the return type could be used for? In that case, my comment makes no sense, sorry for the noise. Do you know how the matching handles interfaces with parameters? Would isAssignableFrom match on them? 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. I realized that the sorting is likely also necessary for constructors, in case you have overloaded constructors for a class... Seems possible to use almost identical code where the sorting in cpp.py is done for the constructors. Yes, we have the same bug there. Andi..
