Proposal to add symbol: "hasInstanceStrict"

[Aleksander Efremov]

I offered use syntax which a lot of developers already know and it would be
intuitively clear to use it.

21 февр. 2018 г. 9:15 пользователь "Александр Ефремов" <mr.efrem at gmail.com>
написал:

>
>
> 20 февр. 2018 г., в 22:32, Mike Samuel <mikesamuel at gmail.com> написал(а):
>
>
>
> On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <
> tj.crowder at farsightsoftware.com> wrote:
>
>> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesamuel at gmail.com>
>> wrote:
>> >
>> > I'm probably just going to echo themes that T.J. has dealt with better,
>> but:
>>
>> Quite the opposite.
>>
>> And keying off Mike's excellent summary: I like the idea of providing a
>> means of handling preconditions (and postconditions), of which runtime type
>> checking is one example but only one. I'd just prefer to see it as a
>> general mechanism than type-checking specifically.
>>
>> I suggest getting deep into the decorators stuff and helping push it
>> forward, possibly into areas where it hasn't previously been headed (such
>> as your `let x = sum(y, y)` where you want to have runtime type checking on
>> what gets assigned to `x` -- as far as I know, that isn't even on their
>> radar). Basically that's applying a precondition to the assignment to `x`
>> (or a postcondition on the call to `sum`). Which could be interesting. You
>> may or may not get agreement on pushing forward that far, but if you feel
>> strongly about the functionality you're after, I see that as the direction
>> to pursue. (Not that I'm in ANY way any kind of authority on moving things
>> through the process here. Not remotely.)
>>
>> -- T.J. Crowder
>>
>
> One way that decorators (I keep saying annotations) for locals might work
> is:
>
> @foo
> const x = initialValue
> f(x)
>
> desugars to
>
> const x = foo(undefined, initialValue)
> f(foo(x))
>
> When the decorated local is used as a left-hand side, the use is wrapped
> in a call to the decorator.
> When the decorated local is used as a right-hand side, the value assigned
> is the result of the decorator applied to the previous value and the
> candidate value.
>
> I think that would be enough to build guards upon.
>
>
> I don’t understand how it will be comfortable to write decorators for
> checking arguments of every function with different set of arguments:
>
> ```
> function a(b: PrimitiveNumber) {}
>
> function a1({ x: PrimitiveBoolean, d: PrimitiveString }) {}
>
> function a2(e: PrimitiveString, { f: PrimitiveNumber, g: PrimitiveString
> }, j: PrimitiveBoolean) {}
> ```
>
> and etc. For every case I should to create separate decorator? It will
> also isn’t comfortable. And use decorators for locals for my goal me seems
> also more verbose and isn’t comfortable.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180221/422185b0/attachment.html>