tag:blogger.com,1999:blog-6069439299305224730.post6564530290482362805..comments2023-03-22T15:06:21.232+01:00Comments on zoom.nu: Const correctnes and callback interfaces in CAnonymoushttp://www.blogger.com/profile/01044897049984478240noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6069439299305224730.post-61811397137978301432010-03-23T11:13:02.079+01:002010-03-23T11:13:02.079+01:00No, they actually do it correctly. Year.atMonth re...No, they actually do it correctly. Year.atMonth returns YearMonth, which has a different methods than Year (including, of course, a different atDay). They really do it properly, even though I suspect that it's different objects in use, and not a single object with many types.<br /><br />And you really should learn Objective CAML or Haskell. You will like it.Anonymoushttps://www.blogger.com/profile/01044897049984478240noreply@blogger.comtag:blogger.com,1999:blog-6069439299305224730.post-54165888386938273862010-03-13T13:37:10.200+01:002010-03-13T13:37:10.200+01:00Yes, that is an interesting and clever thought. I ...Yes, that is an interesting and clever thought. I wonder what a good practice would be for that, maybe the callback function should receive the calling object as a parameter. Otherwise the callback-function might hold on to an object reference that is not "valid" anymore since the object state has changed.<br /><br />When I was looking at the JSR-310 spec (the "will they finally get it right-spec" for date and times in Java) there is an example of builder methods:<br /><br />Year.of(2010).atMonth(MonthOfYear.FEBRUARY).atDay(26).atTime(12, 30).atOffset(ZoneOffset.of("+03:00"));<br /><br />This chain of method calls to build the state of an object is close to what we were talking about, although in this particular example I guess all methods return the same type.<br /><br />So I got to thinking: imagine a language where you could not hold references to objects and all state is hidden behind interfaces. You would have no direct access to "memory" - only functions you could call that returned a new interface and maybe had some side effects like I/O.<br /><br />I realized I had invented functional programing all over again. It seems to happen more frequently the older I get :-DZoomhttps://www.blogger.com/profile/18242700034929571579noreply@blogger.comtag:blogger.com,1999:blog-6069439299305224730.post-83822430767450715832010-03-12T08:22:16.572+01:002010-03-12T08:22:16.572+01:00Yes, that's what I was implying by "as lo...Yes, that's what I was implying by "as long as the documentation for do_something_with_callback specifies exactly how if will call f". A horror story from Windows Mobile is the Radio Interface Layer API, which is entirely callback based (fair enough, it has a reason to be asynchronous in some places), but does not mention the threading model at all. Using it is almost impossible when you have to handle that your callback may be called from<br />* your own thread,<br />* a thread that is shared by all callbacks,<br />* a global callback calling thread,<br />* a thread talking to a lower layer that mustn't be delayed for any reason, or<br />* some other random thread,<br />before or after the call you made returns, repeatedly, simultaneously, or not called at all. Oh, and no mention of whether you can call any part of the API from within your callback. Designing the module that would call the RIL was an interesting challenge (since I wanted to write it according to the "spec", and not by testing and guessing like it appears everyone else does).<br /><br />Anyway, back to your point. Yes, maybe this can be combined with what we discussed before with object state being exposed as different interfaces. Maybe the callback should be passed a restricted version of the object that called it, so that it is easy to see what can be called at this point, and what cannot.Anonymoushttps://www.blogger.com/profile/01044897049984478240noreply@blogger.comtag:blogger.com,1999:blog-6069439299305224730.post-64325166785874682612010-03-11T18:02:27.727+01:002010-03-11T18:02:27.727+01:00The pitfalls of callback-functions are many, obscu...The pitfalls of callback-functions are many, obscure and deep. Even in a language lika Java where this particular const-correctness does not apply there are many others. One particular favourite is the listener/event pattern where you loop a list of listeners, make a callback and the callback mutates the lsit of listeners.Zoomhttps://www.blogger.com/profile/18242700034929571579noreply@blogger.com