By “typed arrays” the idea is something like this:
https://mattferderer.com/difference-between-array-types-in-typescript
> On Jan 11, 2019, at 9:04 PM, Kessler CTR Mark J
> wrote:
>
> Just a side note. Are already supported in JS[1] and you use the new names
> [2] directly such as your
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.
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
Thanks for the thoughtful response, Alex. I think we're on the right track here.
> IMO, having more restrictive rules for AS is "ok" if we can make it PAYG,
> which it sort of is. You should be able to use plain objects if you don't
> want Closure's minification. I think you can set your
@Josh: I'm going to try to answer both of your posts in this one reply.
IMO, having more restrictive rules for AS is "ok" if we can make it PAYG, which
it sort of is. You should be able to use plain objects if you don't want
Closure's minification. I think you can set your compiler options
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
> 3) That other classes linked into your final JS file can dictate what keys
> are renamed
Again, we're seeing Closure's advanced renaming causing trouble and making us
jump through hoops. We've already seen that it makes JSON difficult to use, and
Harbs needed a new compiler option added so
This feels very wrong to me.
Having to implement an interface or create a conversion function to pass
parameters to native JS APIs from ActionScript is going to be a massively,
enormously, gigantic headache for everyone. Developers aren't going to want to
write boilerplate to use native APIs.
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
Let me try to respond to everyone in this one post:
@Josh: I don't think we would ever disallow the use of Object literals in
Royale. But I expect there to be more and more reasons to avoid using them
over time. Already we know that:
1) The IDE's don't really know what to code-hint when you
I'm all for strongly typed / static typed everything when available for
compile and run times. However here is some side information on the ECMA
(2015) typed arrays[1] and the ongoing discussion / notes for the full static
type implementation [2] that was proposed by Sirisian's (pretty
] branch develop
updated: Fix implicit coercion error)
Harbs, the approach you're describing is also similar to Haxe's anonymous
structures and typedefs which are also compile-time only (but broader than
just getter/setters and regular methods in terms of typing). It works
across all Haxe's (many
Essentially, you want to defeat strong-typing...
On 1/7/19, 2:34 AM, "Harbs" wrote:
> In your proposal, every place we fake the type, we have to use "as
BlobPropertyBag" and @royaleignorecoercion BloBPropertyBag.
No. I’m proposing making the compiler smarter so you *wouldn’t*
To be clear:
I have no objection to using factory functions run places where it makes sense.
My issue is more that we have no other option.
Thanks,
Harbs
> On Jan 7, 2019, at 12:34 PM, Harbs wrote:
>
>> In your proposal, every place we fake the type, we have to use "as
>> BlobPropertyBag"
In your proposal, every place we fake the type, we have to use "as
BlobPropertyBag" and @royaleignorecoercion BloBPropertyBag. Because otherwise,
your very first line:
var options:BlobPropertyBag = { type: "text/plain”};
will generate a compiler error as you wrote it. Plus you are
I feel like you’re not understanding me.
I’m proposing:
var options:BlobPropertyBag = { type: "text/plain”};
new Blob(null, options);
Which would compile to:
var options/** @type {BlobPropertyBag} */ = { type: "text/plain”};
new Blob(null, options);
Using my proposal, this will work in the new
Hi,
sorry for annoying you but there's something which I'd like to understand:
If I understand it correctly, the issue is caused by the recent Google
Closure thing which expects typed constructor parameters now.
If I got it right, Google Closure is used for the JS target only.
So, it seems to me
Some runtimes understand types. We should not defeat that. The runtime
optimization of types is usually better than untyped stuff. JS in the browser
is an exception and may be only a temporary popular runtime in the long term.
The pattern I proposed (createBlobPropertyBag) is a
Feel free to make the changes. I personally am trying to ensure type-safety
instead of weaken it. It is only this case where the cost is starting to
outweigh the benefits.
Why would it be huge? Why should we encourage the use of plain objects intead
of classes? It feels to JS-specific.
Personally, I would like to have us support TypeScript-type interfaces where
plain objects that have the correct properties pass the check.[1]
I have no idea how difficult this would be for SWF-compatible code, but even if
it’s supported for JS-only code, that would be a huge production
20 matches
Mail list logo
