OK, but shouldn’t the right-hand side be resolved into a literal Object? When
an “external type” is expected and it’s an Object, why can’t there be a lazy
evaluation of the Object to see if it matches the required signature of the
external dynamic type?
That seems like it would not have any overhead if extern types are not used,
but can allow resolution of dynamic types if they are used.
Of course, I’m much less of an expert than you though…
We can try and implement this as an optional compiler flag and see what happens…
> On Jan 10, 2019, at 8:51 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Note: I've read Josh's more recent posts and I think he's heading towards
> the right answer so I will respond there separately, but wanted to address
> your technical questions for the record.
>
> Again, I am not a compiler/language expert. I'm just going with my mental
> model based on working on the compiler over the past years.
>
> The source code is parsed into an AST (a tree of nodes). An assignment
> statement becomes a BinaryOperatorNode. The "=" is the operator and there is
> a leftOperandNode and rightOperandNode. I think the compiler has lots of
> expectations that the rightOperandNode can be resolved to a type, and lots of
> expectations that types must behave according to the rules of ActionScript.
> In this case, that an Object cannot be coerced to a class instance.
>
> So, right now, the rightOperandNode will resolve to be Object. I think you
> are suggesting that you want to change resolveType to keep walking up the
> tree of nodes across the operator to the leftOperandNode. That seems slow
> and may result in big changes to the compiler. I don't think a
> BinaryOperatorNode is even an Expression which is a concept for nodes that
> can resolve to a type.
>
> If you want to "declare" an Object literal as a type, you might write:
>
> BlobPropertyBag({ type: "text/plain"})
>
> That defines the rightOperandNode as an expression of type BlobPropertyBag.
> Hence why I think Conversion functions are useful. Now on to Josh's posts.
>
> My 2 cents,
> -Alex
>
> On 1/10/19, 1:59 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
> I don’t know what you mean here.
>
> My proposal would not change anything for literals which are typed as
> Object.
>
> I’m proposing that literals that are declared as “typdefed” types would be
> checked against the typedefs. (I like the use of “typedef” as Haxe does
> rather than “interface” to avoid confusion with real interfaces.)
>
> I don’t understand what performance problems you envision and I don’t
> understand why this would create language issues.
>
> Harbs
>
>> On Jan 10, 2019, at 10:47 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>>
>> @Harbs: I am not a language/compiler expert, but I do not think that
>> languages typically have literals that are automatically coerced to types.
>> I believe the AST node tree of the literal can be
>> reduced/compiled/transpiled without knowing that it is part of an assignment
>> statement. I believe your proposal is to change that, and I am concerned
>> about the compiler performance and language issues that could arise from
>> that. I would strongly recommend we don't do that and stay with constructs
>> that are more common to other languages.
>
>
>
