AsyncAsync.log

Oct 08 15:08:11 <spion> a library that promisifies and exports something
Oct 08 15:08:23 <spion> and you want to monkey patch the original something's xAsync
Oct 08 15:08:51 <spion> wait.
Oct 08 15:09:10 <spion> what do you do when both x() and xAsync() exist?
Oct 08 15:09:17 <spion> what does the first one promisify to?
Oct 08 15:09:26 <Petka> xAsync and xAsyncAsync
Oct 08 15:09:50 <Petka> the api reference mentions this too
Oct 08 15:10:02 <spion> okay
Oct 08 15:10:06 <Petka> if xAsync honestly has that suffix and is not promisified then it will have
 AsyncAsync
Oct 08 15:10:07 <spion> so you can still use .x()
Oct 08 15:10:12 <Petka> ye
Oct 08 15:10:17 <Petka> it doesn't overwrite
Oct 08 15:10:19 <spion> but you can't use xAsync() ?
Oct 08 15:10:22 <spion> ah
Oct 08 15:10:25 <Petka> so only sealed and frozen objects are a problem
Oct 08 15:10:37 <Petka> and prevent extensions
Oct 08 15:10:43 <spion> how about the original xAsync method, is it accessible?
Oct 08 15:11:02 <Petka> ohhhhhhh
Oct 08 15:11:36 <Petka> well yea if you have object with x and xAsync ... original xAsync is not ac
cessible :D
Oct 08 15:11:42 <Petka> good catch
Oct 08 15:15:49 <Petka> and xAsyncAsync would call this.xAsync thinking it's a function that takes 
nodeback
Oct 08 15:18:45 <spion> Yeah. If you ask me, mutation simply creates too many problems :)
Oct 08 15:19:10 <spion> the reason was efficiency, right?
Oct 08 15:19:17 <spion> you have direct access to .this
Oct 08 15:19:38 <Petka> the generated function will dynamically access this. instead of using bindi
ng
Oct 08 15:19:52 <spion> yeah I thought so.
Oct 08 15:20:28 <spion> i wonder if its possible to somehow return a new prototype chain instead.
Oct 08 15:20:35 <Petka> storing the original node function in closure would solve the problem partl
y
Oct 08 15:21:27 <Petka> and would not affect performance much since it will always call that same f
unction identity
Oct 08 15:22:20 <spion> yes you can definitely do that
Oct 08 15:22:37 <spion> and you can make the original accessible by appending Original until you fi
nd a free name
Oct 08 15:22:38 <spion> :)))
Oct 08 15:23:01 <spion> i'm not sure thats a good idea though
Oct 08 15:23:23 *       waysc2 has quit (Ping timeout: 259 seconds)
Oct 08 15:24:17 <spion> one thing that comes to mind though is that promisifiers should be separate
 libraries
Oct 08 15:24:19 <Petka> err actually it would affect perf since it changes from this.fn() to fn.cal
l(this)
Oct 08 15:24:25 <spion> then you could use the one most suited for the task
Oct 08 15:24:51 <Petka> and for some reason there is no optimization for .call yet
Oct 08 15:25:07 <spion> how about the xAsyncOriginal idea?
Oct 08 15:25:08 <spion> :)
Oct 08 15:25:42 <Petka> why original? Why not just some random key like bb12032
Oct 08 15:26:16 <Petka> so if Im getting this right:
Oct 08 15:26:22 <Petka> store original fn on the object with random prefix