{"action":"reopened","issue":{"url":"https://api.github.com/repos/gracelang/language/issues/37","repository_url":"https://api.github.com/repos/gracelang/language","labels_url":"https://api.github.com/repos/gracelang/language/issues/37/labels{/name}","comments_url":"https://api.github.com/repos/gracelang/language/issues/37/comments","events_url":"https://api.github.com/repos/gracelang/language/issues/37/events","html_url":"https://github.com/gracelang/language/issues/37","id":132666347,"number":37,"title":"how to write alias clauses to cope with overriding on arity","user":{"login":"kjx","id":1917107,"avatar_url":"https://avatars.githubusercontent.com/u/1917107?v=3","gravatar_id":"","url":"https://api.github.com/users/kjx","html_url":"https://github.com/kjx","followers_url":"https://api.github.com/users/kjx/followers","following_url":"https://api.github.com/users/kjx/following{/other_user}","gists_url":"https://api.github.com/users/kjx/gists{/gist_id}","starred_url":"https://api.github.com/users/kjx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kjx/subscriptions","organizations_url":"https://api.github.com/users/kjx/orgs","repos_url":"https://api.github.com/users/kjx/repos","events_url":"https://api.github.com/users/kjx/events{/privacy}","received_events_url":"https://api.github.com/users/kjx/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/gracelang/language/labels/design","name":"design","color":"5319e7"},{"url":"https://api.github.com/repos/gracelang/language/labels/resolved:%20needs%20to%20be%20spec'd","name":"resolved: needs to be spec'd","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2016-02-10T10:51:58Z","updated_at":"2016-02-16T22:34:11Z","closed_at":null,"body":"Currently, without overloading by arity, we write\r\n\r\n    use someTrait\r\n         alias other()name() = foo()bar()\r\n\r\nwhich ignores arity, and lets programmers (particularly novices) ignore arity.   If someTrait has more than one foo()bar() method, we don't know which method to rename. \r\n\r\nOptions like\r\n\r\n    use someTrait\r\n         alias other(1)name(2) = foo(2)bar(1)\r\n         alias other(_)name(_,_) = foo(_),bar(_,_) \r\n         alias other(x) = foo(y)bar(\"bar\")\r\n\r\nare either ugly, syntactically encourage options we don't want, and all make clear the potential for overriding on arity when really I'd really like to hide that for as much and as long a possible.\r\n\r\nIf we have to override on arity, I propose three evil rules cases:\r\n\r\n1. write arities only on the RHS (renaming cannot change arities or redistribute arguments amongst parts)\r\n2. if there is only one method in the trait, omit arities even on the RHS\r\n3. trailing ()s can always be omitted\r\n\r\n\r\n```\r\n    use someTrait\r\n         alias other()name() = foo(2)bar(1)\r\n         alias myLocalName = nonOverriddenMethodInTheTrait \r\n         alias myMulti()LocalName() = anotherNonOverridden()MethodInTheTrait() \r\n\r\n```\r\n\r\nThis means that, up until **standardGrace** at least, programmers can totally ignore overloading on arities.  We hates them my precious. Hates them. \r\n\r\nOk: thinking a bit more, how about just one rule  (the \"Neutral Bomb\" rule)\r\n\r\n1. never write arities. aliasing makes new names, leaves arguments & arities exactly the same.\r\n\r\nWe keep exactly the same syntax we have now, and simply \"coherently\" rename **all** overloaded methods in the same way.  That's it. That's all. Hah. You know what, if we must do this, that's probably my preference. \r\n"}}