Calling toString on function proxy throws TypeError exception

[Mark Miller]

I like the idea a function proxy is more encapsulating of its
implementation than a function is.

I also like the idea of treating a function proxy as a builtin callable,
rather than a function written in JS, and return something like "function
() { [function proxy] }" as Tom suggested or "function () { [native code]
}" as Claude suggested. We need progress on the draft spec for F.p.toString
reform, including the standardized pattern for the function sources that
are not supposed to parse, e.g., "function () { [...stuff...] }".



On Mon, Oct 26, 2015 at 1:17 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

>
> > On Oct 23, 2015, at 6:43 AM, Claude Pache <claude.pache at gmail.com>
> wrote:
> >
> > Almost every method found on `Function.prototype` "works" (or, at least,
> does not throw a TypeError before trying to work) if and only if the target
> is callable, or if and only if `typeof` applied to the target produces
> `"function"`.
> > That should not be different for `Function.prototype.toString()`. Even
> if "working" means producing a useless string à la `"function () { [native
> code] }"`.
> >
> > —Claude
> >
>
> Right, I should have look closer at the actual spec for  call, apply, and
> blind rather than depending upon memory.  The reason they work on proxies
> is that they only depend upon the MOP API of their this object. In other
> words, they are generic across  all object that have a [[Call]] internal
> method.
>
> Function.prototype.toString is different in that it is dependent upon the
> actual internal structure of the object is is applied to rather than the
> object’s MOP API. This is necessary because F.p.toString must access
> information (the source code of the function or the ability to recreate it)
> that is not available through the MOP.  As I’ve mentioned in earlier
> messages, F.p.toString is in this regard like all other methods that
> directly access private internal state.
>
> F.p.toString could be respecified to explicitly recognize proxies and
> drill through them but it isn’t clear why F.p.toString should be singled
> out from all other private state accessing buiit-in methods in this regard.
>
> But, let’s assume we did make F.p.toString drill through callable
> proxies.  What are the implications.
>
> First remember, that a callable proxy can only be created on a target
> object that already has a [[Call]] internal method. The target might itself
> be a callable proxy, but ultimately the chain of targets must reach an
> object that has a primitive [[Call]] behavior.  This would normally be
> either an ECMAScript function object or a built-in function object.
>
> So, while it is perfectly reasonable to define a callable proxy that, for
> example, in its [[Call]] handler runs a Lisp interpreter over a captured
> S-expression, such a proxy   must either directly or indirectly have as its
> target an ECMAScript function. If you were defining such a proxy where the
> Lisp interpreter is embedded within its [[Call]] handler, you might use
> something like: `function() {}` as the target. If you apply an enhanced
> proxy drill throughing F.p.toString to such a proxy you would get the
> source code for `function() {}`.  How is that useful?
>
> Another way, to implement our Lisp interpreting proxy would be to use as
> the target an ECMAScript function that actually implements the Lisp
> interpreter. In that case, the [[Call]] handler would simply call the
> target function passing the captured S-expression to it as an argument.  If
> you apply an enhanced proxy drill throughing F.p.toString to that sort of a
> proxy you would get back the source code for the Lisp interpreter. This
> seems potentially harmful.  Revealing the source code of the Lisp
> interpreter might reveal exploitable secrets. Heck, the very fact that a
> Lisp interpreter is being used might be a secret.
>
> So, why would we want to do this?
>
> Allen
>
>


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151026/a8101f67/attachment-0001.html>