{"action":"created","issue":{"url":"https://api.github.com/repos/daokoder/dao/issues/423","labels_url":"https://api.github.com/repos/daokoder/dao/issues/423/labels{/name}","comments_url":"https://api.github.com/repos/daokoder/dao/issues/423/comments","events_url":"https://api.github.com/repos/daokoder/dao/issues/423/events","html_url":"https://github.com/daokoder/dao/issues/423","id":92119411,"number":423,"title":"Re-thinking the aspect class syntax","user":{"login":"Night-walker","id":5074460,"avatar_url":"https://avatars.githubusercontent.com/u/5074460?v=3","gravatar_id":"","url":"https://api.github.com/users/Night-walker","html_url":"https://github.com/Night-walker","followers_url":"https://api.github.com/users/Night-walker/followers","following_url":"https://api.github.com/users/Night-walker/following{/other_user}","gists_url":"https://api.github.com/users/Night-walker/gists{/gist_id}","starred_url":"https://api.github.com/users/Night-walker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Night-walker/subscriptions","organizations_url":"https://api.github.com/users/Night-walker/orgs","repos_url":"https://api.github.com/users/Night-walker/repos","events_url":"https://api.github.com/users/Night-walker/events{/privacy}","received_events_url":"https://api.github.com/users/Night-walker/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":12,"created_at":"2015-06-30T15:08:47Z","updated_at":"2015-07-03T17:28:01Z","closed_at":null,"body":"A minor issue with aspect classes lies in the fact that they represent a separate kind of entity in the language. That is, we have classes, abstract interfaces, concrete interfaces *and* aspect classes. At the same time, aspect classes are nothing more than ordinary classes mixed-in automatically to all compatible targets. \r\n\r\nThus aspect classes are essentially a macro-feature used to make class compositions. So why not decouple it from class declarations? It could look like this:\r\n```ruby\r\nclass Mixin {\r\n    ...\r\n}\r\n\r\nimport Mixin for Target # following the present pattern semantics\r\n\r\nclass Target {\r\n    ...\r\n}\r\n```\r\nHere `import-for` (or `import-in`) is just a directive to glue ordinary classes together without introducing any extra layer of complexity. \r\n\r\nObvious advantages:\r\n1) Elision of needless language entity. No more magic @-prefixed classes which one should distinguish from ordinary classes.\r\n2) Ability to automatically mix-in any fitting class. Instead of declaring *ad-hoc* aspect classes for certain scenario, one might adopt existing classes for this role without changing the related source. \r\n\r\nAlso, I like to see `import` keyword here, as it does conceptually the same thing as with namespace importing :)\r\n\r\nAs for disadvantages, as of now I see none. I believe that in this case a fine-grained design, one with smaller 'bricks' easily combinable with each other, is apparently superior to a coarse-grained design with larger and more complex 'bricks'."},"comment":{"url":"https://api.github.com/repos/daokoder/dao/issues/comments/118397481","html_url":"https://github.com/daokoder/dao/issues/423#issuecomment-118397481","issue_url":"https://api.github.com/repos/daokoder/dao/issues/423","id":118397481,"user":{"login":"Night-walker","id":5074460,"avatar_url":"https://avatars.githubusercontent.com/u/5074460?v=3","gravatar_id":"","url":"https://api.github.com/users/Night-walker","html_url":"https://github.com/Night-walker","followers_url":"https://api.github.com/users/Night-walker/followers","following_url":"https://api.github.com/users/Night-walker/following{/other_user}","gists_url":"https://api.github.com/users/Night-walker/gists{/gist_id}","starred_url":"https://api.github.com/users/Night-walker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Night-walker/subscriptions","organizations_url":"https://api.github.com/users/Night-walker/orgs","repos_url":"https://api.github.com/users/Night-walker/repos","events_url":"https://api.github.com/users/Night-walker/events{/privacy}","received_events_url":"https://api.github.com/users/Night-walker/received_events","type":"User","site_admin":false},"created_at":"2015-07-03T17:28:01Z","updated_at":"2015-07-03T17:28:01Z","body":"> To certain extent, this applies to import-in vs aspect classes as well.\r\n> Regarding keywords, I am not sure, but I take this as your preference for import-in over aspect, right?\r\n\r\nI wasn't clear enough. I actually meant ordinary classes (plus little extra `import-in`) vs aspect classes.\r\n\r\n> BTW, using separate statements such as import-in is also a lot more flexible than aspect classes.\r\n\r\nYes. Smaller, simpler things are usually more flexible as well."}}