Supporting feature tests directly

Bill Frantz frantz at
Thu Mar 26 20:36:58 UTC 2015

On 3/26/15 at 8:51 AM, getify at (Kyle Simpson) wrote:

>As I mentioned near the beginning of this thread, 
>`Reflect.parse(..)` would generally suit the proposed use-case, 
>except it does a lot of extra work (creating and returning a 
>tree -- a value that then I'd be throwing away creating 
>unnecessary GC) that feature testing itself doesn't need. It's 
>unclear that `Reflect.parse(..)` would provide any additional 
>performance gains over the current `eval` / `Function` 
>approach, and could even be potentially worse.

I don't see a real need for high performance in these tests. 
AFAICS, they occur once, probably at load time. A smart JS 
implementation might even parse the Reflect.parse() string at 
the same time it is parsing the main set of JS code. As such, 
the extra overhead for CPU and GC will probably be swamped by 
the communication CPU and transmission times.

Not using eval makes it more likely that you will be able to 
perform the tests in "safe" subsets of JS.

Cheers - Bill

Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave |              - Scott McNealy | Los Gatos, 
CA 95032

More information about the es-discuss mailing list