RE: Proposal: Default object method

There’s nothing in that proposal says that an object with a `Symbol.apply` has to have a different `typeof`. It *would* mean that any Call might require additional dispatch which could have performance implications. It could also be an approach to support “callable” classes: ```js class Foo {

Re: Proposal: Default object method

Jordan's right. This one is best handled by a function. But if there is some reason you need to create callable objects, it's still doable, even with ES as-is. Just extend your classes from something like this: ```js class Callable { constructor(defaultFn) { return (...args) => { return d

Re: Proposal: Default object method

Something that can be invoked has a `[[Call]]` slot, and is `typeof` "function". Adding a Symbol that makes something callable would have a number of effects - it would make `typeof` (one of the most robust operations in the language) unsafe, because it would have to access the Symbol method, whic

Proposal: Default object method

Apologies if this has been raised before. I was unable to locate anything similar. Any thoughts or ideas on this proposal would be appreciated! Original: https://gist.github.com/brasten/f87b9bb470973dd5ee9de0760f1c81c7 -Brasten

Re: Native Assertions

Good to know that has moved forward, but it is still minimally relevant due to the other points raised. Also as an FYI the following paper from OOPSLA 2018: Collapsible Contracts: Fixing a Pathology of Gradual Typing https://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla2018-fgsfs.pdf On

Re: Native Assertions

console.assert is standardized by the WHATWG at https://console.spec.whatwg.org/#assert. Sebastian On Mon, 14 Jan 2019 at 12:39, Michael Haufe wrote: > console.assert is not standardized at this point, nor is it part of the > language. Additionally, the semantics are inappropriate for the requi