{"action":"created","issue":{"url":"https://api.github.com/repos/typelevel/cats/issues/989","repository_url":"https://api.github.com/repos/typelevel/cats","labels_url":"https://api.github.com/repos/typelevel/cats/issues/989/labels{/name}","comments_url":"https://api.github.com/repos/typelevel/cats/issues/989/comments","events_url":"https://api.github.com/repos/typelevel/cats/issues/989/events","html_url":"https://github.com/typelevel/cats/pull/989","id":149663370,"number":989,"title":"Remove internal lazy val from Later.","user":{"login":"non","id":218045,"avatar_url":"https://avatars.githubusercontent.com/u/218045?v=3","gravatar_id":"","url":"https://api.github.com/users/non","html_url":"https://github.com/non","followers_url":"https://api.github.com/users/non/followers","following_url":"https://api.github.com/users/non/following{/other_user}","gists_url":"https://api.github.com/users/non/gists{/gist_id}","starred_url":"https://api.github.com/users/non/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/non/subscriptions","organizations_url":"https://api.github.com/users/non/orgs","repos_url":"https://api.github.com/users/non/repos","events_url":"https://api.github.com/users/non/events{/privacy}","received_events_url":"https://api.github.com/users/non/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/typelevel/cats/labels/in%20progress","name":"in progress","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":12,"created_at":"2016-04-20T05:28:02Z","updated_at":"2016-05-03T00:24:44Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/typelevel/cats/pulls/989","html_url":"https://github.com/typelevel/cats/pull/989","diff_url":"https://github.com/typelevel/cats/pull/989.diff","patch_url":"https://github.com/typelevel/cats/pull/989.patch"},"body":"This commit replaces the previous Later implementation\r\nwith one that is not based on Scala's lazy val encoding.\r\n\r\nConcretely, this new implementation uses a private,\r\ninternal lock to avoid potential deadlocks that could\r\narise if other objects synchronized on a Later instance.\r\nThe possibility of this happening is relatively remote\r\nbut not impossible.\r\n\r\nPerformance seems to be equivalent to lazy vals in the\r\ncases that were tested. An additional Object is\r\nallocated, so Later instance may be slightly larger.\r\n\r\nIs this a good idea? Should we stick with `lazy val`?\r\nShould we synchronize on `this` to have smaller\r\ninstances? Should we be doing something else?"},"comment":{"url":"https://api.github.com/repos/typelevel/cats/issues/comments/216403131","html_url":"https://github.com/typelevel/cats/pull/989#issuecomment-216403131","issue_url":"https://api.github.com/repos/typelevel/cats/issues/989","id":216403131,"user":{"login":"johnynek","id":67958,"avatar_url":"https://avatars.githubusercontent.com/u/67958?v=3","gravatar_id":"","url":"https://api.github.com/users/johnynek","html_url":"https://github.com/johnynek","followers_url":"https://api.github.com/users/johnynek/followers","following_url":"https://api.github.com/users/johnynek/following{/other_user}","gists_url":"https://api.github.com/users/johnynek/gists{/gist_id}","starred_url":"https://api.github.com/users/johnynek/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/johnynek/subscriptions","organizations_url":"https://api.github.com/users/johnynek/orgs","repos_url":"https://api.github.com/users/johnynek/repos","events_url":"https://api.github.com/users/johnynek/events{/privacy}","received_events_url":"https://api.github.com/users/johnynek/received_events","type":"User","site_admin":false},"created_at":"2016-05-03T00:24:44Z","updated_at":"2016-05-03T00:24:44Z","body":"the serialization was exercised by the semigroup serialization check (indeed that is why we added the code).\r\n\r\nI hear you that it is pretty defensive to worry about locks on `this`. I don't mind locking `this` I guess. I would never lock an object I didn't create since I have no idea who else might lock it, so I guess it is clearly dangerous, and this is scala, so we assume programmers know about sharp edges and avoid them.\r\n"}}