On 12/11/16, 10:48 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>On Dec 12, 2016, at 7:52 AM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>> On 12/11/16, 10:28 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>>> I DO want renaming.
>>>
>>> My point is that we really need to have an option to disable renaming
>>>in
>>> specific places in the code.
>>>
>>> My example is a very classic case when interop between outside code is
>>> going to cause problems. I CAN’T use class definitions everywhere.
>>>There
>>> needs to be a method to properly deal with that.
>>>
>>> I don’t have types for JSZip, and create extern files for every use of
>>> third party libraries is not a practical option.
>>
>> I don't understand why you can't use class definitions or don't have
>> types. The whole point of the externs for third-party libraries is to
>> have an AS API for a external JS API. Create a JSZip class with a
>> generateNodeStream function. Generate Value Objects for their objects
>> that are passed in as objects. In the final JS, everything is plain
>> objects.
>>
>> Public class NodeStreamParam
>> {
>> Public const NODE_BUFFER:String = "nodeBuffer";
>> Public var type:String;
>> Public var streamFiles:Boolean;
>> }
>>
>> Public class JSZip
>> {
>> Public function generateNodeStream(nsp:NodeStreamParam):NodeStream
>> {
>> return null;
>> }
>> }
>>
>
>AFAIU, this will not prevent renaming unless there is a extern js file
>for the Google Compiler — which I don’t have.
If you use FalconJX to compile that AS you will have your externs file.
>
>Also, there’s lots of APIs that take object literals. Requiring to
>declare classes for each of these raise the overhead for simple
>implementations. A lot of folks will be copying code off Stack Overflow
>or wherever. Rather than it just “working”, they would have a lot of
>extra overhead. Making that a REQUIREMENT is something I think we should
>avoid.
It is only a requirement if you want to use ADVANCED_OPTIMIZATIONS, which
folks don't have to use. And you'd have to use the same techniques
(externs, quotes) to prevent renaming.
The reason to create an AS API for a 3rd party library is more than just
preventing renaming. It is to allow the compiler to check your code so
you don't also get hosed by typing zip["fnerateNdeStrm"] Or pass it
"{typ: "nodbufr"}. If you don't want to use strong typing, why use FlexJS
in the first place?
>
>>
>>>
>>> If you read my email you will see I already stated that using quoted
>>> strings is the work-around here, but IMO, it’s not a solution to
>>>require
>>> client code to always do that.
>>
>> I'm not clear any sort of annotation would be any easier for the person
>> writing the code. You have to remember when to use the annotation or
>> remember to use the quotes. There might be a way to make it easier to
>> generate the externs for a third party library. If you were to have .AS
>> files for JSZip and NodeStreamParam like I do above, maybe we can teach
>> the compiler to look for an @externs and treat the file as an extern.
>> Similarly, the compiler might be able to package such a file in the SWC
>> differently than it does now.
>
>I like this idea for generating externs, but for my examples I was
>thinking of something simpler:
>
>1. instead of:
>var zip:* = new JSZip();
>or
>var zip:Object = new JSZip();
>
>we could enable:
>var zip:Extern = new JSZip();
>
>and the compiler would know that “Extern” is of type Object, but all
>methods and properties should have string bracket notation instead of dot
>notation.
I think that would slow down the compiler. It would have to test every
output against the type of object. We could do it if enough folks ask,
but IMO, externs and strong-typing will save you lots of other mistakes.
>
>2. We should have a compiler option (on by default) where all untyped
>object literals be written with quoted string literals. So:
>var obj:Object = {foo:true,baz:10};
>could be rewritten, but
>var obj:* = {foo:true,baz:10};
>would compile as:
>var obj = {“foo":true,”baz":10};
>and the names would be preserved by the compiler
>Similarly:
>
>myThingy.doSomething({foo:true,baz:10})
>
>would compile as:
>myThingy.doSomething({“foo":true,”baz":10})
Also possible, but as soon as you turn the option off, you'll be wishing
for those externs and class definitions.
-Alex
