| 02:34 | <jridgewell> | > rlwarp |
| 02:34 | <jridgewell> | WHY HAVE I NEVER HEARD OF THIS? |
| 08:02 | <Yoonseok> | Hello. Is there any reliable mechanism to identify a type of a given function object? I want to know whether this function is normal, generator, async, and so on. |
| 08:26 | <Yoonseok> | Oh. *mechanism* seems misleading. I want to find a reliable way to identify a type of a function. |
| 13:59 | <bradleymeck> | Yoonseok: they do have different prototypes, but in general they could always return stuff and act as other things, e.g. it is common for a normal function to return the promise of an async function |
| 14:00 | <bradleymeck> | Yoonseok: so, even if you know the type, it generally isn't useful |
| 14:01 | <bradleymeck> | fun stuff also happens when sometimes we have seen functions passed into node's builtins with null prototypes via Object.setPrototypeOf(()=>{}, null) |
| 14:01 | <bradleymeck> | so even prototypes aren't necessarily a good route |
| 14:02 | <Yoonseok> | yes. Indeed, prototypes is mutable. So, it is not reliable. |
| 14:02 | <Yoonseok> | hm. i'm thinking about "it generally isn't useful". |
| 14:03 | <Yoonseok> | for a given function, i want to provide a kind of secure layer that filter out leaking a secret by return value. |
| 14:04 | <Yoonseok> | but, without knowing the type of a given function, it is not possible to provide a secure layer for the function. (mostly, this layer is a wrapper function). |
| 14:05 | <Yoonseok> | in the case of generator, it returns a generator object, and you can call the it by generator.next(), which is out of my scope. |
| 14:06 | <Yoonseok> | indeed, it is not surprising even though js does not support a feature to identify a type of object. |
| 14:07 | <Yoonseok> | but, in other cases, such as Date, RegExp, we can observe the type by applying the object to "Date.prototype.getTime" or "RegExp.prototype.test". |
| 14:08 | <Yoonseok> | but, I really cannot find it for generator or async functions. |
| 14:10 | <Yoonseok> | in practice, we can apply `Function.prototype.toString`, but it is not standard (so, XS or JerryScript does not return its content), |
| 14:11 | <Yoonseok> | moreover, Function.prototype.bind removes it. |
| 14:13 | <Yoonseok> | bradleymeck anyway. thank you for the response. :) |
| 14:15 | <bradleymeck> | Yoonseok: I mean, Function.prototype.bind.call(fn) will give you a *new* function with the proper prototype |
| 14:15 | <Yoonseok> | ah. |
| 14:16 | <bradleymeck> | but it won't be useful for determining how the return value works |
| 14:16 | <bradleymeck> | normal functions can return iterators/promises/etc. |
| 14:16 | <bradleymeck> | or wait, not it won't it just inherits |
| 14:16 | <bradleymeck> | my brain is waking up still |
| 14:16 | <Yoonseok> | it is correct. okay. i had some assumption. |
| 14:21 | <Yoonseok> | okay. i will check it first. I'm thinking about whether I can implement a membrane that allows me to pass a generator. |
| 14:56 | <Yoonseok> | bradleymeck thank you. i think that you're right. such type information is not useful. they are all just a function that returns a different type of values. |
| 14:59 | <bradleymeck> | Yoonseok: in general what Membranes if they are crossing a barrier do for such things is to wrap all the return values if they are objects if you look at lightning web components, es-membrane, or SES |
| 15:03 | <Yoonseok> | i'm looking at the current limitation of membranes. since membrane relies on proxy feature and proxy feature does not allow to access internal slots, membrane does not guarantee the identity of objects (here, identity means internal slots). for example, if a regular expression object o is passed via membrane, you cannot use "abc".test(o) because o |
| 15:03 | <Yoonseok> | is not a regular expression object anymore. |
| 15:03 | <Yoonseok> | I think it is the same for the generator function. |
| 15:04 | <Yoonseok> | generator function returns a generator object, and (of course, no one really want to use this) if anyone want to call the generator object gfn by `(function*(){}).constructor.prototype.prototype.next.apply(gfn)`, it will fail. because gfn is not a generator object (it is a proxy). |
| 15:05 | <Yoonseok> | ah. when gfn is obtained by a generator function passed via the membrane (the barrier). |
| 15:06 | <Yoonseok> | I thought that there is a way to improve it if we know the type of a function. but, you're right. we can't even if we know the type. |
| 15:12 | <Yoonseok> | uh. i really want to rewrite whole sentences. sorry for the mess sentences. :/ |
| 16:27 | <devsnek> | ljharb: i can't tell what your suggested change does |
| 16:27 | <devsnek> | i hate that github won't highlight it |
| 16:28 | <ljharb> | spells additionally properly |
| 16:28 | <devsnek> | oh cool |