{"action":"created","issue":{"url":"https://api.github.com/repos/eclipse/golo-lang/issues/334","labels_url":"https://api.github.com/repos/eclipse/golo-lang/issues/334/labels{/name}","comments_url":"https://api.github.com/repos/eclipse/golo-lang/issues/334/comments","events_url":"https://api.github.com/repos/eclipse/golo-lang/issues/334/events","html_url":"https://github.com/eclipse/golo-lang/pull/334","id":123644245,"number":334,"title":"Refactor method and augmentation resolution","user":{"login":"yloiseau","id":7151021,"avatar_url":"https://avatars.githubusercontent.com/u/7151021?v=3","gravatar_id":"","url":"https://api.github.com/users/yloiseau","html_url":"https://github.com/yloiseau","followers_url":"https://api.github.com/users/yloiseau/followers","following_url":"https://api.github.com/users/yloiseau/following{/other_user}","gists_url":"https://api.github.com/users/yloiseau/gists{/gist_id}","starred_url":"https://api.github.com/users/yloiseau/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yloiseau/subscriptions","organizations_url":"https://api.github.com/users/yloiseau/orgs","repos_url":"https://api.github.com/users/yloiseau/repos","events_url":"https://api.github.com/users/yloiseau/events{/privacy}","received_events_url":"https://api.github.com/users/yloiseau/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-12-23T11:36:23Z","updated_at":"2015-12-30T10:53:14Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/eclipse/golo-lang/pulls/334","html_url":"https://github.com/eclipse/golo-lang/pull/334","diff_url":"https://github.com/eclipse/golo-lang/pull/334.diff","patch_url":"https://github.com/eclipse/golo-lang/pull/334.patch"},"body":"Change the way (augmented) methods are resolved at runtime, to deal\r\nwith the priorities discussed in #326.\r\n\r\nMove methods common between augmentation and regular method resolution\r\ninto a abstract superclass.\r\n\r\nRefactor method type matching, to better reuse and move it to the\r\nMethodInvocation object.\r\n\r\nFIX #275\r\n\r\nAlso some refactoring on tests.\r\n\r\nFIX: empty augmentation\r\n\r\nNot filled as an issue, but a class was generated to hold augment\r\nfunctions, even if there was no functions. This happened when using\r\nnamed augmentation, since a single IR node is created for declarations\r\nsuch as\r\n\r\n    augment Foo {\r\n      function plop = |this| -> \"plop\"\r\n    }\r\n\r\nand\r\n\r\n    augment Foo with Plop\r\n\r\nIn the first case a class `module$Foo` is created to hold the `plop`\r\nfunction. It was also created in the second case, but was empty."},"comment":{"url":"https://api.github.com/repos/eclipse/golo-lang/issues/comments/167976349","html_url":"https://github.com/eclipse/golo-lang/pull/334#issuecomment-167976349","issue_url":"https://api.github.com/repos/eclipse/golo-lang/issues/334","id":167976349,"user":{"login":"jponge","id":25961,"avatar_url":"https://avatars.githubusercontent.com/u/25961?v=3","gravatar_id":"","url":"https://api.github.com/users/jponge","html_url":"https://github.com/jponge","followers_url":"https://api.github.com/users/jponge/followers","following_url":"https://api.github.com/users/jponge/following{/other_user}","gists_url":"https://api.github.com/users/jponge/gists{/gist_id}","starred_url":"https://api.github.com/users/jponge/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jponge/subscriptions","organizations_url":"https://api.github.com/users/jponge/orgs","repos_url":"https://api.github.com/users/jponge/repos","events_url":"https://api.github.com/users/jponge/events{/privacy}","received_events_url":"https://api.github.com/users/jponge/received_events","type":"User","site_admin":false},"created_at":"2015-12-30T10:53:14Z","updated_at":"2015-12-30T10:53:14Z","body":"@yloiseau Just in case you have time, a boolean method in `RegularMethodFinder` to check if we are in presence of a Java overloaded method would help (for the method name, several methods have the same number of arguments).\r\n\r\nI've started a branch to allow dealing with such methods, as in:\r\n\r\n```java\r\n/*\r\n * Copyright (c) 2012-2015 Institut National des Sciences Appliquées de Lyon (INSA-Lyon)\r\n *\r\n * All rights reserved. This program and the accompanying materials\r\n * are made available under the terms of the Eclipse Public License v1.0\r\n * which accompanies this distribution, and is available at\r\n * http://www.eclipse.org/legal/epl-v10.html\r\n */\r\n\r\npackage org.eclipse.golo.compiler.testing.support;\r\n\r\npublic class ClassWithOverloadedMethods {\r\n\r\n  public String foo(String str) {\r\n    return \"# \" + str;\r\n  }\r\n\r\n  public String foo(int i) {\r\n    return \"% \" + i;\r\n  }\r\n}\r\n```\r\n\r\nI made a first commit with a unit test, and while I looked into `RegularMethodFinder` and `MethodInvocationSupport`, I thought that I'd better wait for that PR to be merged.\r\n\r\nBTW I think the strategy for overloaded methods will be a simple inline-cache with a `guardWithTest` that checks for receiver *and* argument types. For performance reasons I'll probably make several arity guard targets before falling back to an array boxing one above a certain number of arguments)."}}