> > >> Scala has a notion of "extractor" objects: >> http://www.scala-lang.org/node/112 – with the right method signatures, >> they can be used like a function, or be used in pattern matching (or for >> us, destructuring only - for now). I can see how this would be useful, and >> could be achieved using private names instead of method signatures. The >> result would be an object that could still be typeof "object" and also >> callable. >> >> import {apply,unapply} from "@extractor"; >> >> const Twice = { >> [apply]:function(x){ >> return x * 2; >> }, >> [unapply]:function(z){ >> return z%2 == 0? z/2 : null; >> } >> } >> >> let x = Twice(21); // x == 42 >> let Twice(n) = x; // n == 21 >> >> I think the unapply half could be useful in destructuring, though I think >> it would be distinctly more useful in pattern matching (which I would love >> to see included). Or the unapply half could just be dropped if too >> problematic. >> > > <3 > > Of course, we'd need a completely different pattern for duck-testing > callables. If functions were re-specified to include the `apply` private > name then testing for its presence may be enough. This would fall down in > the face of naive iframe-sandboxing -- is this a big problem? If so, at > worst sandboxes could use a proxy to alias the various apply brands (I > suspect there's a lighter weight strategy that could work too -- I only say > this to note the benefits of using brands for psuedo-typing). > >
It could just be something as simple as Object.isCallable or Function.isCallable, though I agree it would be nice if Function used it as well - that would go along with the idea of putting intrinsic builtin stuff in privates like with Date. - Russ
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
