{"action":"created","issue":{"url":"https://api.github.com/repos/mattlockyer/composables-998/issues/28","repository_url":"https://api.github.com/repos/mattlockyer/composables-998","labels_url":"https://api.github.com/repos/mattlockyer/composables-998/issues/28/labels{/name}","comments_url":"https://api.github.com/repos/mattlockyer/composables-998/issues/28/comments","events_url":"https://api.github.com/repos/mattlockyer/composables-998/issues/28/events","html_url":"https://github.com/mattlockyer/composables-998/issues/28","id":340846481,"node_id":"MDU6SXNzdWUzNDA4NDY0ODE=","number":28,"title":"Very confusing naming/design with TopDown and BottomUp","user":{"login":"vernon99","id":667546,"node_id":"MDQ6VXNlcjY2NzU0Ng==","avatar_url":"https://avatars2.githubusercontent.com/u/667546?v=4","gravatar_id":"","url":"https://api.github.com/users/vernon99","html_url":"https://github.com/vernon99","followers_url":"https://api.github.com/users/vernon99/followers","following_url":"https://api.github.com/users/vernon99/following{/other_user}","gists_url":"https://api.github.com/users/vernon99/gists{/gist_id}","starred_url":"https://api.github.com/users/vernon99/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vernon99/subscriptions","organizations_url":"https://api.github.com/users/vernon99/orgs","repos_url":"https://api.github.com/users/vernon99/repos","events_url":"https://api.github.com/users/vernon99/events{/privacy}","received_events_url":"https://api.github.com/users/vernon99/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-13T01:00:46Z","updated_at":"2018-07-13T07:21:54Z","closed_at":null,"author_association":"NONE","body":"Why was 998 the contract split and renamed in two? Top down and bottom up. Doesn't make much sense to me both conceptually (only the parent should be composable) and in terms of the naming. Parent should be parent. Child should be child and may have a separate extra interface to communicate with the parent. I suggest to rename ERC998ERC721TopDown back to simply ERC998. And have ERC998Child interface if you want to have extra logic for the children, callbacks from the parents, etc. Like look at what ERC721 done with ERC721 and ERC721Receiver."},"comment":{"url":"https://api.github.com/repos/mattlockyer/composables-998/issues/comments/404749145","html_url":"https://github.com/mattlockyer/composables-998/issues/28#issuecomment-404749145","issue_url":"https://api.github.com/repos/mattlockyer/composables-998/issues/28","id":404749145,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNDc0OTE0NQ==","user":{"login":"achadha235","id":1176261,"node_id":"MDQ6VXNlcjExNzYyNjE=","avatar_url":"https://avatars3.githubusercontent.com/u/1176261?v=4","gravatar_id":"","url":"https://api.github.com/users/achadha235","html_url":"https://github.com/achadha235","followers_url":"https://api.github.com/users/achadha235/followers","following_url":"https://api.github.com/users/achadha235/following{/other_user}","gists_url":"https://api.github.com/users/achadha235/gists{/gist_id}","starred_url":"https://api.github.com/users/achadha235/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/achadha235/subscriptions","organizations_url":"https://api.github.com/users/achadha235/orgs","repos_url":"https://api.github.com/users/achadha235/repos","events_url":"https://api.github.com/users/achadha235/events{/privacy}","received_events_url":"https://api.github.com/users/achadha235/received_events","type":"User","site_admin":false},"created_at":"2018-07-13T07:21:54Z","updated_at":"2018-07-13T07:21:54Z","author_association":"CONTRIBUTOR","body":"Both interfaces enable token composition through two different implementations.  Both interfaces can be combined or used independently to enable a specific use cases, with their own set of advantages and disadvantages. It helps to think about which contract implements the capability for token possession. In the top down case, it is in the possessor and in the other it is within the possession.  From a design perspective, I think separating these two ideas makes a **lot** of sense.\r\n\r\nAs for the naming, I agree with you completely - the words \"top down\" and \"bottom up\" really give no information about the capabilities of these two interfaces. Nothing about the words \"ERC\" / \"998\" / \"Top\" / \"Down\" / \"Bottom\" / \"Up\" says anything about \"token possession\". Good interface names communicate it's capability in a few clear words. In our case, communicating which contract implements the **possession capability** is vital. \r\n\r\nWhile the words \"parent\" and \"child\" add something more, I think they still miss the target because you can have complex parent-child relationships independent of which interface is used. In other words, child-parent relationships can exist whether you use top-down or bottom-up composition and hence the parent/child terminology does little to disambiguate which case you're talking about. Furthermore, you can also have cases where something is both a parent and a child. Instead of parent / child, I like to think of it in terms of owners / possessions and where this capability is implemented. \r\n\r\nMy $0.02 here: The Top Down interface should be called **ERC998TokenPossessor**. It is more evident a \"token possessor\" contract would implement the capability for itself to possess other tokens. Similarly, the Bottom Up interface should be called **ERC998TokenPossession** - again it is clearer that a \"token possession\" contract would implement functionality to allow it to be possessed by another token. This is also more consistent with the overall idea of NFT Token *Possessions*. In the hybrid / combined ERC998 case, it is conceptually more meaningful for a contract to be a \"token possessor\" and a \"token possession\" simultaneously than both top-down/bottom-up or parent/child."}}
{"actor":{"display_login":"achadha235"}}