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;
}
}
>
>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.
Thoughts?
-Alex
