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
nd need to someday return a real concrete instance
> that implements the interface.
>
> Thoughts?
> -Alex
>
>
> On 12/26/18, 11:02 PM, "Yishay Weiss" wrote:
>
> Sounds good, feel free to revert.
>
>
>
> ______
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
opertyBag
> >> {
> >> // return a plain object but fool the compiler into thinking it is an
> implementation of the interface
> >> return {} as BlobPropertyBag;
> >> }
> >>
> >> IMO, this also future-proofs the code in case we ever run wh
tween what Yishay
tried and the interface implementations I did, which is to have a factory that
returns an instance of the interface, but actually returns a plain object. As
long as no code actually tests that the instance implements the interface, it
should work. And that would localize the coe
ha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID
>>>>>>> <mailto:aha...@adobe.com.INVALID>>>> wrote:
>>>>>>>
>>>>>>> I just fixed a bug in the compiler, and now we are getting more of
>>>>>
actory that
returns an instance of the interface, but actually returns a plain object. As
long as no code actually tests that the instance implements the interface, it
should work. And that would localize the coercion of a plain object to an
interface in relatively few known places in our code.
>&
t;>> solution because it looks funny to have lots of places in our code where
>>>>> a plain object is coerced to a type.
>>>>>
>>>>> So, I went and created classes that implement BlobPropertyBag and other
>>>>> interfaces. I didn't like a
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
>>
>> Thoughts?
>> -Alex
>>
>>
>> On 12/26/18, 11:02 PM, "Yishay Weiss" wrote:
>>
>> Sounds good, feel free to revert.
>>
>>
>>
>> ___
e to revert.
>
>
>
>________
> From: Alex Harui
> Sent: Thursday, December 27, 2018 3:43:45 AM
>To: dev@royale.apache.org; comm...@royale.apache.org
>Subject: Re: [royale-asjs] branch develop updated: Fix impli
ay return a real concrete instance
> that implements the interface.
>
> Thoughts?
> -Alex
>
>
> On 12/26/18, 11:02 PM, "Yishay Weiss" wrote:
>
>Sounds good, feel free to revert.
>
>
>
> ____
>From: Alex Harui
feel free to revert.
From: Alex Harui
Sent: Thursday, December 27, 2018 3:43:45 AM
To: dev@royale.apache.org; comm...@royale.apache.org
Subject: Re: [royale-asjs] branch develop updated: Fix implicit coercion
error
I don't think we should hack it like this. Ca
feel free to revert.
> >>
> >>
> >>
> >>
> >> From: Alex Harui
> >> Sent: Thursday, December 27, 2018 3:43:45 AM
> >> To: dev@royale.apache.org; comm...@royale.apache.org
> >> Subject: Re: [royale-a
t; To: dev@royale.apache.org; comm...@royale.apache.org
>> Subject: Re: [royale-asjs] branch develop updated: Fix implicit coercion
>> error
>>
>> I don't think we should hack it like this. Casting a plain object to a
>> type makes the code look strange, and it might
ert.
>
>
>
>
> From: Alex Harui
> Sent: Thursday, December 27, 2018 3:43:45 AM
> To: dev@royale.apache.org; comm...@royale.apache.org
> Subject: Re: [royale-asjs] branch develop updated: Fix implicit coercion
> error
>
> I don't think w
Sounds good, feel free to revert.
From: Alex Harui
Sent: Thursday, December 27, 2018 3:43:45 AM
To: dev@royale.apache.org; comm...@royale.apache.org
Subject: Re: [royale-asjs] branch develop updated: Fix implicit coercion error
I don't think we should hack
I don't think we should hack it like this. Casting a plain object to a type
makes the code look strange, and it might not minify correctly. I have a
different fix I hope to put in shortly where we actually pass in an instance of
the BlogPropertyBag.
-Alex
On 12/26/18, 6:57 AM,
26 matches
Mail list logo
