Yes, the right hand side will be an Object (literal or not). The left hand
side is evaluated to be a type. Then there is a test to see if the two match.
It isn't simple equality since you have to compare subtypes and interfaces, but
this proposal adds one more test if there isn't a match. These tests happen
often when compiling any piece of code, and I don't think there is a central
test either.
I think Josh is right in that a Closure interface is a different construct than
in ActionScript, so we shouldn't try to re-purpose AS Interfaces for all output
targets. It will be far fewer changes to the compiler to modify ExternC to
annotate the APIs and have the transpiler do the check.
My 2 cents,
-Alex
On 1/10/19, 1:49 PM, "Harbs" <harbs.li...@gmail.com> wrote:
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.
>
>
>
