Personally I feel that TypeScript is only trying to be strong typed
language and it's definitely less typed than ActionScript. - I mean here
that whole environment do not propagate idea of strong typing.
You don't have any problems doing such things: let myField = something; -
No type declaration at all.
Of course I imagine that you can switch many things so compiler in
TypeScript can tells you that you are doing something untyped. However I
like ActionScript even more cause it's always "force" you at some point
make "as IMyInterface", cast things and have proper type. No one like
situation when you have some warnings during compilation, cause type is not
declared etc.
This is something which I don't like in TypeScript and this is something
which I would love to do not see in Royale. - The idea that you at some
point can omit type somewhere.
Sorry guys if it's actually not fully related to that thread.
Piotr
pon., 7 sty 2019 o 11:43 Alex Harui <aha...@adobe.com.invalid> napisał(a):
> Essentially, you want to defeat strong-typing...
>
> On 1/7/19, 2:34 AM, "Harbs" <harbs.li...@gmail.com> 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* have
> to do that. With the compiler improvements, I don’t see why an IDE couldn’t
> offer code intelligence. In fact, I’m pretty sure that it’s already offered
> for TypeScript.
>
> I’m not asking you to do this. If you don’t want to spend the time
> making these changes to the compiler, that’s fine. I’m willing to try and
> figure out how I can get it done.
>
> Thanks,
> Harbs
>
> > On Jan 7, 2019, at 12:27 PM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >
> > 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
> proposing a lot of changes to the compiler. And you won't get any help
> from the IDE when you type that "{".
> >
> > I am proposing that we do the "as BlobPropertyBag" and
> @royaleignorecoercion BloBPropertyBag in one place in our code, in a
> factory function not every place we create a Blob. Then you will get code
> completion. And we only take the chance that we mistype the property names
> once.
> >
> > -Alex
> >
> > On 1/7/19, 2:14 AM, "Harbs" <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>> wrote:
> >
> > 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 Closure Compiler AND
> we’d get compile time type checking on the object. (i.e. { tpye:
> "text/plain”}; or { type: true}; would cause an error at compile time.)
> >
> > Using your proposal, the closure compiler will not complain, but
> there’s no actual checking that the object is correct.
> >
> > Does that make more sense?
> > Harbs
> >>
> >> On Jan 7, 2019, at 11:54 AM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >>
> >> A plain object cannot implement an interface. As soon as something
> checks (the compile, or the code, or the runtime, or the IDE), an error
> will be reported. In the JS runtime, nobody checks. IF we use
> @royaleignorecoercion, our code won't. But the compiler still does.
> >>
> >> Look at the Blob.as generated from royale-typedefs for the Blob
> class. The constructor is:
> >>
> >> public function Blob(opt_blobParts:Array = null,
> opt_options:BlobPropertyBag = null)
> >>
> >> The opt_options is not expecting a plain object. So, if you write
> code like:
> >>
> >> new Blob(null, { type: "text/plain"})
> >>
> >> You will get an error because the plain object is not a
> BlobPropertyBag (which is an interface, not a class). In the browser, you
> can get away with passing in the plain object if you can tell the compiler
> to not check the type or lie and use "as BlobPropertyBag", but I think we
> should use factory functions instead of plain objects where possible. It
> isn't the "smallest code" option, but the result is more portable to other
> platforms and IDEs understand it. So my latest proposal is something like:
> >>
> >> /** @royaleignorecoercion BlobPropertyBag */
> >> public function createBlobPropertyBag(type:String =
> "text/plain"):BlobPropertyBag
> >> {
> >> return { "type": type } as BlobPropertyBag;
> >> }
> >>
> >> So that the code we write looks like:
> >>
> >> New Blob(null, createBlobPropertyBag("text/plain"));
> >>
> >> Again, the IDEs can code-hint it, and other runtimes could generate
> an actual instance of a class. Google is changing its typedefs in a way
> that our typedef SWCs don't let you pass in plain objects. We "lie" to the
> compiler once in createBlobPropertyBag, so we don't have to lie every time
> we create a Blob.
> >>
> >> -Alex
> >>
> >>
> >>
> >>
> >>
> >> On 1/7/19, 1:34 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>
> >> Can you point me to what you’re talking about? Something is not
> making sense to me.
> >>
> >> BlobPropertyBag[1] is an interface for a plain object. That’s the
> W3C spec AIUI. If th3 closure compiler is expecting types, than I assume
> it’s expecting a comment which declares the parameter of the plain object
> to be of the type of this interface. The interface is *not* a true runtime
> interface. It’s a “dynamic” interface which declares that the object will
> contain specific properties. This is exactly the way that the Typescript
> interfaces work.
> >>
> >> All I’m proposing is that instead of requiring factory functions
> for any case where we need a dynamic interface for a dynamic object (i.e.
> BlobPropertyBag) which unfortunately is a pretty common problem in the JS
> world, we could declare these dynamic interfaces as what they really are.
> >>
> >> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FFileAPI%2F%23dfn-BlobPropertyBag&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871052350&sdata=Cj%2BYg8ogybGD7ZxbkNwWYNQlkHufN09KHUNwOluIksA%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FFileAPI%2F%23dfn-BlobPropertyBag&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=%2BXH0hDiwSQ0B5c1fbEYyWby85HQj%2Bif0fOShqi7Z7pc%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FFileAPI%2F%23dfn-BlobPropertyBag&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=%2BXH0hDiwSQ0B5c1fbEYyWby85HQj%2Bif0fOShqi7Z7pc%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FFileAPI%2F%23dfn-BlobPropertyBag&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=%2BXH0hDiwSQ0B5c1fbEYyWby85HQj%2Bif0fOShqi7Z7pc%3D&reserved=0
> >>
> >>
> >>> On Jan 7, 2019, at 11:14 AM, Alex Harui <aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID>> wrote:
> >>>
> >>> Google Closure Library wants a typed init object, not an untyped
> event object. So it is opposite of what you say. We are forced to use a
> typed object. If I understand your recommendation, you are proposing to
> use untyped objects as passing them in as typed objects. The more we
> encourage folks to type "{" in their code, the less portable their code
> will be to other platforms, and the IDEs will not be able to help without
> upgrades to the IDEs.
> >>>
> >>> If you want to add checking to places that require passing in a
> plain object, you can use the "middle-ground" idea of using metadata, or
> you can do what Google Closure did and define an interface with the
> properties that should go in the object. The latter is more portable to
> future runtimes and the IDEs can help catch mistakes.
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>> On 1/7/19, 1:07 AM, "Harbs" <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>>> wrote:
> >>>
> >>> I don’t think I’m proposing defeating types.
> >>>
> >>> I’m suggesting we should have compile time type checking in cases
> where we’re forced to use untyped objects. This will *improve* type
> checking.
> >>>
> >>> In cases where it’s practical to have strongly typed runtime
> instances, I’m all for the runtime improvements.
> >>>
> >>> My $0.02,
> >>> Harbs
> >>>
> >>>> On Jan 7, 2019, at 10:37 AM, Alex Harui <aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID>> wrote:
> >>>>
> >>>> 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
> platform-independent abstraction that allows SWF and future platform code
> to actually generate a type where the JS code could get away with a plain
> object. But maybe we should modify that proposal a bit so that the factory
> function takes optional initialization parameters as well.
> >>>>
> >>>> Type-safety has some development-time overhead. That's why folks
> like AS over Java. You don't have to strongly-type everything.
> Unfortunately, it isn't our call that Google has decided to strongly type
> the init objects in the browser. Well, it is our call in that we can
> change the interfaces we generate, but I'm not sure we should. We want to
> have folks write code that can work on other runtimes, and future runtimes
> are likely to understand types. Using plain objects might seem easy/fast
> now, but it is likely to be a problem in the future.
> >>>>
> >>>> I believe if we use this factory pattern, you should also never
> waste time spell checking plain objects ever again. The IDEs already know
> how to code-hint an interface. They don't know what to do when you type
> "{". IOW, if you type:
> >>>>
> >>>> new window.Event("foo", {
> >>>>
> >>>> the current Royale IDEs will not help you, but if you instead
> use the proposed pattern:
> >>>>
> >>>> new window.Event("foo", createEventInit(
> >>>>
> >>>> the IDE will offer the list of init properties. And your code
> will work on future runtime/platforms.
> >>>>
> >>>> I think it would be a substantial change to the compiler to allow
> plain objects where an interface is expected. The parameters are checked
> in the ABCReducer, even for JS output. The midde-ground would be to say
> the parameter is an Object and use metadata to tell the JS transpiler to
> check the properties against an interface. I don't think we check the
> ArrayElementType metadata today, but we could someday if we don't fake
> generics. But again, that code has little chance of working on future
> platforms without more layering underneath.
> >>>>
> >>>> My 2 cents,
> >>>> -Alex
> >>>>
> >>>> On 1/6/19, 11:37 PM, "Harbs" <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>> <mailto:harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>>>> wrote:
> >>>>
> >>>> There are three advantages to Typescript-style interfaces:
> >>>>
> >>>> 1. There’s less typing and passing around objects is easier.
> >>>> 2. Plain objects are actually type checked. Instead of lying to
> the compiler by using “as”, the compiler can check that the required
> properties exist and are spelled correctly.
> >>>> 3. They completely disappear at runtime. “True” interfaces add
> bulk at runtime needed for reflection and the like.
> >>>>
> >>>>> Why would it be huge?
> >>>>
> >>>> From experience, the time spent casting and spellchecking plain
> objects is very time consuming when you have a need for lots of plain
> objects. This happens more often than you’d like in the “real world”…
> >>>>
> >>>> I’m envisioning two types of interfaces:
> >>>>
> >>>> 1. Classic interfaces like we have now. This would offer runtime
> checking and reflection. It would also offer type safety for future
> strongly typed languages.
> >>>> 2. “Dynamic” or “Virtual” interfaces would offer type checking
> for dynamic objects at compile-time only.
> >>>>
> >>>> I’m thinking of maybe decorating interfaces with [Dynamic] or
> [Virtual] to tell the compiler that it’s a “fake” interface.
> >>>>
> >>>> Maybe we can support these kinds of interfaces in SWF output by
> simply converting the type to “Object”. You wouldn’t get the runtime
> checking, but you’d still get the compile-time checking.
> >>>>
> >>>> It might be possible to do something similar in Swift or Java,
> etc. too.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Jan 7, 2019, at 8:37 AM, Alex Harui <aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID>>> wrote:
> >>>>>
> >>>>> 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. Future runtimes might
> have strict type-safety.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 1/6/19, 10:05 PM, "Harbs" <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>>> wrote:
> >>>>>
> >>>>> 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 booster.
> >>>>>
> >>>>> My $0.02,
> >>>>> Harbs
> >>>>>
> >>>>> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=ssX1nBkAt5Rvy2r12G7t0NZmJX8taHBgWk%2Fd1Wb4SlI%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=ssX1nBkAt5Rvy2r12G7t0NZmJX8taHBgWk%2Fd1Wb4SlI%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=ssX1nBkAt5Rvy2r12G7t0NZmJX8taHBgWk%2Fd1Wb4SlI%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=ssX1nBkAt5Rvy2r12G7t0NZmJX8taHBgWk%2Fd1Wb4SlI%3D&reserved=0>>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=ssX1nBkAt5Rvy2r12G7t0NZmJX8taHBgWk%2Fd1Wb4SlI%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871062364&sdata=ssX1nBkAt5Rvy2r12G7t0NZmJX8taHBgWk%2Fd1Wb4SlI%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0>>>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0>>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.typescriptlang.org%2Fdocs%2Fhandbook%2Finterfaces.html&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871072369&sdata=MZVa9e2wX9xWXeRuTTFV%2BIEAYY09e4ytNohaaSNaJLE%3D&reserved=0
> >>>>
> >>>>>
> >>>>>> On Jan 7, 2019, at 6:03 AM, Alex Harui <aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID>> <mailto:aha...@adobe.com.INVALID
> <mailto:aha...@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 these implicit coercion errors because the recent Google Closure
> Typedefs now specify interfaces as parameters to certain contructors (or
> maybe they always did and the compiler is now getting better at catching
> these errors).
> >>>>>>
> >>>>>> Code that looked like:
> >>>>>>
> >>>>>> var blob:Blob = new Blob([text], { type: 'text/plain' });
> >>>>>>
> >>>>>> or
> >>>>>>
> >>>>>> customEvent = new window.Event(type, {bubbles: bubbles,
> cancelable: cancelable});
> >>>>>>
> >>>>>> now results in a compiler error because the plain objects don't
> implement whatever interface of properties the constructor expects. I
> think Google Closure did this so that the properties in the plain object
> don't get renamed by the minifier.
> >>>>>>
> >>>>>> One solution, that Yishay tried in this commit was simply to
> lie to the compiler and tell it that the plain object was a
> BlobPropertyBag. And while that is the "least amount of code" solution, I
> didn’t like that 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 adding the weight of additional class
> definitions but the classes I did were small, just a couple of properties.
> However, for Event,there is a pretty big list of properties just to specify
> bubbles and cancelable. The compiler was not catching that plain object
> before, but now with the fix I just made it will. And I’m not sure it is
> worth adding a large class with lots of properties.
> >>>>>>
> >>>>>> So, I thought of a third idea which is a hack between 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
> coercion of a plain object to an interface in relatively few known places
> in our code.
> >>>>>>
> >>>>>> The pattern would be to create a top-level factory function()
> unless it makes sense to add it to a class so for Blob it might look like:
> >>>>>>
> >>>>>> /**
> >>>>>> * @royaleignorecoercion BlobPropertyBag
> >>>>>> */
> >>>>>> public function createBlobPropertyBag():BlobPropertyBag
> >>>>>> {
> >>>>>> // 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 where
> there is runtime type-checking and need to someday return a real concrete
> instance that implements the interface.
> >>>>>>
> >>>>>> Thoughts?
> >>>>>> -Alex
> >>>>>>
> >>>>>>
> >>>>>> On 12/26/18, 11:02 PM, "Yishay Weiss" <yishayj...@hotmail.com
> <mailto:yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com <mailto:
> yishayj...@hotmail.com>> <mailto:yishayj...@hotmail.com <mailto:
> yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com <mailto:
> yishayj...@hotmail.com>>>> wrote:
> >>>>>>
> >>>>>> Sounds good, feel free to revert.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ________________________________
> >>>>>> From: Alex Harui <aha...@adobe.com.INVALID <mailto:
> aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID <mailto:
> aha...@adobe.com.INVALID>> <mailto:aha...@adobe.com.INVALID <mailto:
> aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID <mailto:
> aha...@adobe.com.INVALID>>>>
> >>>>>> Sent: Thursday, December 27, 2018 3:43:45 AM
> >>>>>> To: dev@royale.apache.org <mailto:dev@royale.apache.org>
> <mailto:dev@royale.apache.org <mailto:dev@royale.apache.org>> <mailto:
> dev@royale.apache.org <mailto:dev@royale.apache.org> <mailto:
> dev@royale.apache.org <mailto:dev@royale.apache.org>>>;
> comm...@royale.apache.org <mailto:comm...@royale.apache.org> <mailto:
> comm...@royale.apache.org <mailto:comm...@royale.apache.org>> <mailto:
> comm...@royale.apache.org <mailto:comm...@royale.apache.org><mailto:
> comm...@royale.apache.org <mailto: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 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, "yish...@apache.org <mailto:
> yish...@apache.org> <mailto:yish...@apache.org <mailto:yish...@apache.org>>
> <mailto:yish...@apache.org <mailto:yish...@apache.org> <mailto:
> yish...@apache.org <mailto:yish...@apache.org>>>" <yish...@apache.org
> <mailto:yish...@apache.org> <mailto:yish...@apache.org <mailto:
> yish...@apache.org>> <mailto:yish...@apache.org <mailto:yish...@apache.org
> ><mailto:yish...@apache.org <mailto:yish...@apache.org>>>> wrote:
> >>>>>>
> >>>>>> This is an automated email from the ASF dual-hosted git
> repository.
> >>>>>>
> >>>>>> yishayw pushed a commit to branch develop
> >>>>>> in repository
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0>>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cca0912af5ee2438eccad08d6748bbe24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824540871082374&sdata=1nnm820tbdYSy7GhUXSUsYYh1KZphPw%2FCMoxxkUUWlk%3D&reserved=0
> >>>
> >>>>>>
> >>>>>>
> >>>>>> The following commit(s) were added to refs/heads/develop by
> this push:
> >>>>>> new 2f127d4 Fix implicit coercion error
> >>>>>> 2f127d4 is described below
> >>>>>>
> >>>>>> commit 2f127d459ee807f197950e11af947c623c270369
> >>>>>> Author: DESKTOP-RH4S838\Yishay <yishayj...@hotmail.com>
> >>>>>> AuthorDate: Wed Dec 26 16:57:33 2018 +0200
> >>>>>>
> >>>>>> Fix implicit coercion error
> >>>>>> ---
> >>>>>>
> .../src/main/royale/org/apache/royale/storage/file/DataOutputStream.as | 2
> +-
> >>>>>>
> .../apache/royale/storage/providers/AndroidExternalStorageProvider.as | 2
> +-
> >>>>>>
> .../royale/org/apache/royale/storage/providers/WebStorageProvider.as | 2
> +-
> >>>>>> 3 files changed, 3 insertions(+), 3 deletions(-)
> >>>>>>
> >>>>>> diff --git
> a/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/file/DataOutputStream.as
> b/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/file/DataOutputStream.as
> >>>>>> index cff76eb..55eab71 100644
> >>>>>> ---
> a/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/file/DataOutputStream.as
> >>>>>> +++
> b/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/file/DataOutputStream.as
> >>>>>> @@ -117,7 +117,7 @@ public class DataOutputStream extends
> EventDispatcher implements IDataOutput
> >>>>>> public function writeText(text:String):void
> >>>>>> {
> >>>>>> COMPILE::JS {
> >>>>>> - var blob:Blob = new Blob([text], { type:
> 'text/plain' });
> >>>>>> + var blob:Blob = new Blob([text], { type:
> 'text/plain' } as BlobPropertyBag);
> >>>>>> _fileWriter.write(blob);
> >>>>>> }
> >>>>>> COMPILE::SWF {
> >>>>>> diff --git
> a/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/AndroidExternalStorageProvider.as
> b/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/AndroidExternalStorageProvider.as
> >>>>>> index ea79a5b..cf05a73 100644
> >>>>>> ---
> a/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/AndroidExternalStorageProvider.as
> >>>>>> +++
> b/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/AndroidExternalStorageProvider.as
> >>>>>> @@ -199,7 +199,7 @@ package
> org.apache.royale.storage.providers
> >>>>>>
> _target.dispatchEvent(newEvent);
> >>>>>> };
> >>>>>>
> >>>>>> - var
> blob:Blob = new Blob([text], { type: 'text/plain' });
> >>>>>> + var
> blob:Blob = new Blob([text], { type: 'text/plain' } as BlobPropertyBag);
> >>>>>>
> fileWriter.write(blob);
> >>>>>> },
> function(e):void {
> >>>>>> var
> errEvent:FileErrorEvent = new FileErrorEvent("ERROR");
> >>>>>> diff --git
> a/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/WebStorageProvider.as
> b/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/WebStorageProvider.as
> >>>>>> index 1632bfa..dd9c84c 100644
> >>>>>> ---
> a/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/WebStorageProvider.as
> >>>>>> +++
> b/frameworks/projects/Storage/src/main/royale/org/apache/royale/storage/providers/WebStorageProvider.as
> >>>>>> @@ -199,7 +199,7 @@ package
> org.apache.royale.storage.providers
> >>>>>>
> _target.dispatchEvent(newEvent);
> >>>>>> };
> >>>>>>
> >>>>>> - var
> blob:Blob = new Blob([text], { type: 'text/plain' });
> >>>>>> + var
> blob:Blob = new Blob([text], { type: 'text/plain' } as BlobPropertyBag);
> >>>>>>
> fileWriter.write(blob);
> >>>>>> },
> function(e):void {
> >>>>>> var
> errEvent:FileErrorEvent = new FileErrorEvent("ERROR");
>
>
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
