> That should solves all cases, right?
Only if a non `:any` type **must** extend `Typed()`. Put another way:
class MyType extends Typed {}
class OtherType {}
let a: any = new Object; //Valid
let b: OtherType; //Error: Invalid type specification
let c: MyType = new Object; //Error: Invalid cast assignment
let d: MyType = new MyType; //Valid
On Fri, Apr 5, 2019 at 3:44 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> we could add a `Typed` primitive every typed value inherits from, similar
> way every object implicitly inherits from `Object` these days.
>
> That, by contract, would disallow any prototype related operation to
> either classes or instances, and it will simplify the
> `Reflect.isTyped(thing)` algo.
>
> class MyType extends Typed {}
> const num:i32 = 123;
>
> the `MyType` class, and every instance of it, cannot have mutated
> prototype, and so cannot the `num`.
>
> Typed values will be all shortcuts that behave like a Typed instance.
>
> That should solves all cases, right?
>
>
>
>
>
> On Thu, Apr 4, 2019 at 8:52 PM Ranando King <king...@gmail.com> wrote:
>
>> > if we base any assumption only to the current highly dynamic nature of
>> JS we won't go too far.
>>
>> Problem is that if we infringe on the "current highly dynamic nature of
>> JS", we'll end up breaking valuable use cases. Any new feature added should
>> always be 100% compatible with the non-competing portions of the existing
>> language.
>>
>> > I think the mutable prototype issue can be solved through static
>> classes where no changes would be possible and all instances would be
>> immune to `setPrototypeOf`
>>
>> That solves half of the problem. What of the other half (`Type v =
>> "somevalue";` where `Type` is not a static class)? With your approach, that
>> would need to be restricted to solve the other half. Otherwise, you'd still
>> be facing the issues Waldemar spoke about.
>>
>> On Thu, Apr 4, 2019 at 2:49 AM Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> If something is missing, let's move forward finding out solutions,
>>> 'cause if we base any assumption only to the current highly dynamic nature
>>> of JS we won't go too far.
>>>
>>> As example, I think the mutable prototype issue can be solved through
>>> static classes where no changes would be possible and all instances would
>>> be immune to `setPrototypeOf`
>>>
>>> ```
>>> static class MyType {}
>>>
>>> Reflect.setPrototypeOf(MyType, Array); // nope
>>> Reflect.setPrototypeOf(new MyType, []); // nope
>>> ```
>>>
>>> we'll also need a `Reflect.isTyped(ref)` in case we'd like to throw
>>> errors on prototype set attempts.
>>>
>>>
>>>
>>> On Thu, Apr 4, 2019 at 6:11 AM Ranando King <king...@gmail.com> wrote:
>>>
>>>> > - If you allow user-defined types, objects can spontaneously change
>>>> their type by mutating their prototype. Thus, you can declare a variable x
>>>> to have type Foo and check that you're assigning an instance of Foo to it,
>>>> but the value x can become a Bar (different from a Foo) spontaneously
>>>> without any operations on x.
>>>>
>>>> At least for static typing, the engine will need to freeze a copy of
>>>> the class definition at the time when the static type is referenced. That
>>>> frozen type will be associated with the variable in a fixed way, making all
>>>> attempts to change the type of the variable fail. Also, that would need to
>>>> divorce the frozen type from the dynamic version so the dynamic version can
>>>> still be mutated. That concept should work, but it might prove to be
>>>> ridiculously complicated since it risks a proliferation of objects all of
>>>> type Foo but with different type definitions. One way to get around that is
>>>> to flag a type as static the first time it is used in a statically typed
>>>> variable definition. This would cause an error to be thrown should any part
>>>> of the class be altered. Not sure how workable that is.
>>>>
>>>> > but that begs the question of what is the type of just ['a', 'b'].
>>>>
>>>> It should be any[]. Typing should be as non-aggressive as possible.
>>>> Auto typing should only consider the top level data to determine the type,
>>>> and in this case, that's an Array. To make c restricted to string elements,
>>>> the type would need to be specified as string[].
>>>>
>>>> > If you follow this to its logical conclusion and think about what the
>>>> types of various methods that work on arrays should be, you end up with an
>>>> enormous and confusing variety of array and object types, which is
>>>> something we explored years ago.
>>>>
>>>> Maybe, but that's always the case with any type system that allows for
>>>> user-defined types. The main problem here is the memory requirements for
>>>> storing all of those types. If I remember the description of V8 internals,
>>>> it seems to have already managed this issue. At least in V8, the challenge
>>>> would be in permanently associating a specific evolution of an internal
>>>> type to a variable.
>>>>
>>>> On Wed, Apr 3, 2019 at 7:50 PM Waldemar Horwat <walde...@google.com>
>>>> wrote:
>>>>
>>>>> On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
>>>>> > This is a proposal for static typing. Here is the github repository
>>>>> link: https://github.com/CreatorVilius/Proposal-Static-Typing
>>>>> > I think it would be great thing in JS.
>>>>>
>>>>> We intentionally reserved syntax so that something like that would be
>>>>> possible in the future.
>>>>>
>>>>> I've also spent a lot of time working on past proposals to do such
>>>>> things. A few interesting issues would invariably arise that make both
>>>>> static and runtime typing unsound:
>>>>>
>>>>> - If you allow user-defined types, objects can spontaneously change
>>>>> their type by mutating their prototype. Thus, you can declare a variable
>>>>> x
>>>>> to have type Foo and check that you're assigning an instance of Foo to it,
>>>>> but the value x can become a Bar (different from a Foo) spontaneously
>>>>> without any operations on x.
>>>>>
>>>>> - Something similar happens with trying to type arrays. You wrote:
>>>>>
>>>>> let c: auto = ['a', 'b'] // c is now string[]
>>>>>
>>>>> but that begs the question of what is the type of just ['a', 'b'].
>>>>>
>>>>> - Is it string[]? No, it can't be that because you can replace its
>>>>> second element with a number.
>>>>> - Is it any[]? Well, in that case c should have type any[], not
>>>>> string[]
>>>>> - Is it object? In that case c should have type Object.
>>>>> and so on.
>>>>>
>>>>> If you follow this to its logical conclusion and think about what the
>>>>> types of various methods that work on arrays should be, you end up with an
>>>>> enormous and confusing variety of array and object types, which is
>>>>> something we explored years ago. In some cases you'd want structural
>>>>> types, in some cases you'd want 'like' types (an array of anything which
>>>>> just happens to hold numbers at the moment), and so on.
>>>>>
>>>>> Waldemar
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
