From dev-return-2862-archive-asf-public=cust-asf.ponee.io@royale.apache.org Sat Feb 17 09:47:50 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id C39BB180657 for ; Sat, 17 Feb 2018 09:47:49 +0100 (CET) Received: (qmail 60396 invoked by uid 500); 17 Feb 2018 08:47:48 -0000 Mailing-List: contact dev-help@royale.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@royale.apache.org Delivered-To: mailing list dev@royale.apache.org Received: (qmail 60371 invoked by uid 99); 17 Feb 2018 08:47:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Feb 2018 08:47:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 886FF180097 for ; Sat, 17 Feb 2018 08:47:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.129 X-Spam-Level: ** X-Spam-Status: No, score=2.129 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id ga0IQX7WfOqb for ; Sat, 17 Feb 2018 08:47:44 +0000 (UTC) Received: from mail-pl0-f51.google.com (mail-pl0-f51.google.com [209.85.160.51]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 71A185F1F3 for ; Sat, 17 Feb 2018 08:47:44 +0000 (UTC) Received: by mail-pl0-f51.google.com with SMTP id t4so2970237plo.0 for ; Sat, 17 Feb 2018 00:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3PMeuE5nryru3C5OuXyomgz1JEDhZtzfL/WfARAqvBE=; b=AU6BeYhueL3z3SkTJDuMtHcYKfyYc3+y3x8681butgSAJBpAEYW9vjMNnsY2Utd4G4 2ki1EGfcPzXu2LnK4f9rsOvyESAgwomPMibKH8p0cREH1ZTJxkVeJrmWHaC+dDtbuZI/ orp5xJ7Q4pD0SPPivWu37DczZ76lXgiP5DYJhdCr4wVj7nbEKcvp8c8ssHgsiuC5/vP6 u7mf5sZ0HTMaNBTOqdJnFnZAIJ1vyDmUXUKMVLqt3/SUybiTFlIsLqvXTP2EtmQJFOCB NC4cMDMK/eoddeePFHbqzU3ZM3vEHcxlyXKKsW3s7+NOVUCc6J0Xe5eGEmmUa+rWCILO OTjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3PMeuE5nryru3C5OuXyomgz1JEDhZtzfL/WfARAqvBE=; b=b6EFU9nsMylLWs2QOJdg1Suto+y1I4GV8FRfNXqe5L+g4mjeBSvhczrjqe51H/8Hmu sPTAEaB98W7ARpPh/pz2u7Z6TQ2MBkfTVvl5g7aCiTtVLhJUqetUjzmpPoFndwZYhI24 0xcINSO4Van47nkd0U+nH/LD/AnbQ2yA8BZGlxe/LPmNHBqj6bGUt1pQRUE8SmTh4lns GUwYU5J16zKMWfNfw4xswiMnsAEC0ozu+Wbl+yqXAXO5jcYhhztNT613tX6ALWRbe99s hKAPve626QPY+9YcJTB7LFRj7qB1pUPf9VeKVHdSkedYXsxF6iZpcSvnKh6bP+KfSQ6d Gpng== X-Gm-Message-State: APf1xPCvoIEduSrJtETp+hcd9K+0HRP0qbcKT/tBXCFbHu4YQ22vrjHG /HsqazIelgzMdbOmjU/fv3iUrGgKi93mP1mSRC4= X-Google-Smtp-Source: AH8x227HXa2kjC/RMJPZ+HaVQf0gkQBHvwJlIOkv5FQGk1M5Ebl1WKFU9C/xXnfQLo9X4zBSUKSrm8AIjvMV8j16ThE= X-Received: by 2002:a17:902:6116:: with SMTP id t22-v6mr8245186plj.307.1518857256912; Sat, 17 Feb 2018 00:47:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Piotr Zarzycki Date: Sat, 17 Feb 2018 08:47:26 +0000 Message-ID: Subject: Re: -remove-circulars To: dev@royale.apache.org Content-Type: multipart/alternative; boundary="0000000000004349fa05656483de" --0000000000004349fa05656483de Content-Type: text/plain; charset="UTF-8" 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 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 > > > > --0000000000004349fa05656483de--