royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: -remove-circulars
Date Sat, 17 Feb 2018 08:47:26 GMT
Hi Alex,

I looks serious. Maybe we szould provide some custom option for compiler.
If someone will have the problem with js-release he will switch up. Behind
the stage remove circular will be also ON.

I do not understand actually how do you suggest to do not remove some
classes? Because if Inunderstand correctly that's what happenning here -
they are removed because they are not used directly.

I have to admit that it may help to one of my example which simply doesn't
work in release version.

Thanks,
Piotr

On Sat, Feb 17, 2018, 06:40 Alex Harui <aharui@adobe.com.invalid> wrote:

> Hi Folks,
>
> I've spent the last day or so trying to get ASDoc to run when minified.  I
> created a JSON to ValueObjects utility which helped a lot.  It still isn't
> completely running, but it appears that we need to stop pruning classes
> that are only used in type annotations.  This will make most apps a little
> fatter, but also require all apps to use remove-circulars.
>
> What do folks think about that?  The compiler used to prune classes from a
> file's goog.requires list that were never instantiated or type-checked in
> that file.  So, for ASDoc, the ASDocClass ValueObject that represents the
> JSON data for the ASDoc is never instantiated by the class that consumes
> it.  The instances are created by JSON.  The ASDocClass is only mentioned
> in JSDoc to declare some variable as being of type ASDoc.  That enabled us
> to remove that class from the requires list since that ASDocClass is never
> referenced by operational code.  Removing that goog.require helped
> eliminate circular goog.require references that the closure compiler
> disallows.  That kicked HTMLElementWrapper out of the app for example.
> But it appears that by removing that goog.require, the compiler didn't
> know that the ASDocClass properties were exported and it renamed some of
> them resulting in problems in js-release.  So by leaving more
> goog.requires in the code we get better support against renaming, but we
> also bring back more circularities and now even HelloWorld would need
> -remove-circulars.
>
> An alternative that would allow a few more apps to not need
> remove-circulars is to modify a few of our examples and classes to
> eliminate circularities.  HelloWorld only has 3.  But 2 of them are
> IParent/IChild and IStrand/IBead.  It seems "right" to have IParent
> reference IChild and vice versa.  Same for IStrand and IBead.  I'm not
> quite sure what the answer is.  Maybe IParent can reference IChild, but
> IChild does not reference its IParent.  I guess you could make an
> IParentedChild interface with the parent property and concrete children
> implement both IChild and IParentedChild.  That seems wrong and overly
> complicated.
>
> Yet another option, which is recommended by some folks in the Closure
> Compiler community but doesn't fit well with the ActionScript language is
> to define both IChild and IParent in the same file.  I do not want to
> spend the time modifying the compiler for that.  It might be practical to
> merge the files as part of the Ant and Maven builds.  But again, that will
> take time as well.
>
> That said, requiring remove-circulars always doesn't seem quite right
> either.
>
> Thoughts?
> -Alex
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message