{"action":"created","issue":{"url":"https://api.github.com/repos/cpw/caps/issues/1","repository_url":"https://api.github.com/repos/cpw/caps","labels_url":"https://api.github.com/repos/cpw/caps/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/cpw/caps/issues/1/comments","events_url":"https://api.github.com/repos/cpw/caps/issues/1/events","html_url":"https://github.com/cpw/caps/pull/1","id":345081364,"node_id":"MDExOlB1bGxSZXF1ZXN0MjA0MzIyODM3","number":1,"title":"My thoughts","user":{"login":"LexManos","id":702211,"node_id":"MDQ6VXNlcjcwMjIxMQ==","avatar_url":"https://avatars3.githubusercontent.com/u/702211?v=4","gravatar_id":"","url":"https://api.github.com/users/LexManos","html_url":"https://github.com/LexManos","followers_url":"https://api.github.com/users/LexManos/followers","following_url":"https://api.github.com/users/LexManos/following{/other_user}","gists_url":"https://api.github.com/users/LexManos/gists{/gist_id}","starred_url":"https://api.github.com/users/LexManos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LexManos/subscriptions","organizations_url":"https://api.github.com/users/LexManos/orgs","repos_url":"https://api.github.com/users/LexManos/repos","events_url":"https://api.github.com/users/LexManos/events{/privacy}","received_events_url":"https://api.github.com/users/LexManos/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-27T03:50:08Z","updated_at":"2018-08-23T08:08:51Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/cpw/caps/pulls/1","html_url":"https://github.com/cpw/caps/pull/1","diff_url":"https://github.com/cpw/caps/pull/1.diff","patch_url":"https://github.com/cpw/caps/pull/1.patch"},"body":"So there are a few things that people seem to want to address.\r\n\r\n1) has/get as two separate functions. The main idea for that was to allow get to be lazy if people only want to check if something has the possibility to support it. But doesnt actually want to access the interface. Solution: Make it one get function, and return type of Optional of some kind, with a lazy value.  This im perfectly fine with. I have issues with cpw's implementation in that it doesn't contractually state that the supplier has to be unique or non-null, on the contrary Suppliers javadocs state the opposite. So to solve that I made NonNullSupplier. And the contract is stated in the docs, and enforced in getValue().\r\n\r\n2) People complaining that they must send in a facing to ItemStacks. I still am convinced that you SHOULD send a facing in. But to shut those people up added a default function in ICapabilityProvider that defaults the side to null. \r\n\r\n3) Caching the result of get, considering it can change at any time. Without a standard way to notify consumers. This can result in people trying to recalculate, say, their energy network every tick. To address this I added the concept of validity to the CapInstance. And a listener list that will be fired when the cap becomes invalid. People can still do their active checking cachedCap.isPresent. But the list allows for a more passive approach {te.getCap(ENERGY, UP).addListener(c -> reCalcEnergyNet())}; I have a small example in my DemoTE. \r\n\r\n4) Custom 'aspects' Honestly I dont think this is feasible, number one question How the hell are people going to get access to those constants from other mods without hard dependencies on those mods? The only good example I have been presented with is extending the player's inventory to have a backpack. And wanting to get specifically that backpack's capability.\r\nThat can be easily accomplished by registering a IBackpackItemHandler extends IItemHandler{} capability. \r\nUnless im convinced by example code that arbitrary custom 'aspects' are possible while maintaining the NUMBER ONE point of Caps, soft dependencies, then I dont think that'll make it into 1.13.\r\n\r\nNow, down to some of my specific things:\r\nCapabilityManager.find(Stirng), I dont see that ever working, Capabilities are identified by their interface class. It keeps everything simple, and type safe. It means people can't register a \"itemhandler\" capability of type IWorldAccess. However, we can use Google's TypeToken to emulate that same find functionality. See my example TE. I kinda like this approach as it moves away from magic annotations. Which it seems you want to do everywhere.\r\n\r\nOn a related note, if we move Capability<T> to a similar Optional system with notifier would allow find() to work on anything, and then replace the @CapabilityInject on methods. \r\n\r\nAnd as you see in my example TE, instead of having the massive object churn by creating new Optional rets every get() call. I show a far more performat, and more logical layout that modders should adopt.\r\n\r\n\r\nI think this is a good middle ground, as it addresse what i think are valid concerns: 1, 2, and 4. \r\nAnd leaves 4 to continue to be discussed with potential for the future."},"comment":{"url":"https://api.github.com/repos/cpw/caps/issues/comments/415329910","html_url":"https://github.com/cpw/caps/pull/1#issuecomment-415329910","issue_url":"https://api.github.com/repos/cpw/caps/issues/1","id":415329910,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNTMyOTkxMA==","user":{"login":"asiekierka","id":113514,"node_id":"MDQ6VXNlcjExMzUxNA==","avatar_url":"https://avatars3.githubusercontent.com/u/113514?v=4","gravatar_id":"","url":"https://api.github.com/users/asiekierka","html_url":"https://github.com/asiekierka","followers_url":"https://api.github.com/users/asiekierka/followers","following_url":"https://api.github.com/users/asiekierka/following{/other_user}","gists_url":"https://api.github.com/users/asiekierka/gists{/gist_id}","starred_url":"https://api.github.com/users/asiekierka/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/asiekierka/subscriptions","organizations_url":"https://api.github.com/users/asiekierka/orgs","repos_url":"https://api.github.com/users/asiekierka/repos","events_url":"https://api.github.com/users/asiekierka/events{/privacy}","received_events_url":"https://api.github.com/users/asiekierka/received_events","type":"User","site_admin":false},"created_at":"2018-08-23T08:08:51Z","updated_at":"2018-08-23T08:08:51Z","author_association":"NONE","body":"\r\n>How the hell are people going to get access to those constants from other mods without hard dependencies on those mods? \r\n\r\nIs there a problem with allowing those constants to have fallbacks? Say, if you use a multipart mod's aspect to query \"the NORTH side, but focusing on the edge between NORTH and DOWN\" - a non-multipart-compatible mod would be able to see that the aspect is looking for the NORTH side and simply return the result for that, ignoring the part about the edge as it's irrelevant to it.\r\n\r\nThis means that the multipart-compatible mod doesn't need to special-case multipart tile entities over non-multipart tile entities anymore (which is a problem for 1.12 multipart mod users), while the non-multipart-compatible mod doesn't need to be aware of multiparts or their constants."}}
{"actor":{"display_login":"asiekierka"}}