Harbs,
I am only proposing this hack specifically for the init object issue (#4).
For every other scenario, I have always and will probably always recommend
classes. If you recall, I have proposed adding a "super-strict" warning in the
compiler that catches all references to plain object to make it easier to
replace every place you are using plain object with a class. Google is sort of
acknowledging my philosophy by replacing the init objects with interfaces.
If class definitions were smaller, I would probably have just created classes
for each init object interface, but I don't want to add the weight and clutter
doc and code-hinting. It just isn't worth it for the obscure init options.
Avoid plain objects entirely if you can. Future runtimes will support class
definitions, but may not support object literals.
-Alex
On 1/7/19, 2:29 AM, "Harbs" <harbs.li...@gmail.com> wrote:
To me, there’s a bigger issue we’re grappling with:
For better or for worse, dealing with untyped objects is a reality in web
development. Web is and will be an important target for Royale for the
foreseeable future. We need a pattern which best deals with this.
Untyped object can come in the form of:
1. JSON
2. API requests which have specific parameters.
3. Interop with external JS. (Something I’ve had to deal with a lot.)
4. Native JS APIs such as the case of BlobPropertyBag that we’re discussing
as an example.
We need to settle on a pattern which deals with these cases. Alex is saying
that using “as” every time we need to avoid a compiler complaining is not a
good pattern. I agree with that.
Alex is proposing factory functions.
I’m proposing “dynamic interfaces” or “typedef” declarations as Greg
pointed out.
HTH,
Harbs
> On Jan 7, 2019, at 12:01 PM, Olaf Krueger <m...@olafkrueger.net> wrote:
>
> 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 that this is a "JS target only" issue which is
currently
> resolved by Yishay's commit [1].
> Even if this is maybe not nice, my understanding is that this is only
needed
> for the JS target, within the "COMPILE::JS" sections.
>
> So, my question is why this issue needs to be resolved "cross-platform"
for
> other targets.
> Is it because of an assumption that other targets may also expect typed
> constructor parameters?
>
> The other question is why we are allowing the usage of these plain objects
> as parameters at all.
> Alex probably already explained it but I don't get it entirely.
> Is it why it would be too much overhead to create all those needed classes
> and interfaces?
> (In case of performance, or in case of effort, ...?).
>
> Thanks in advance!
> Olaf
>
> [1]
> var blob:Blob = new Blob([text], { type: 'text/plain' } as
BlobPropertyBag);
>
>
>
>
> --
> Sent from:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C6090a16403b3489468d408d6748b1124%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636824537972430711&sdata=sne9vheQHysvZNhZUkOZyTZzfapIseoZ00kDeTbMIIU%3D&reserved=0
