Opción ADVANCED_OPTIMIZATIONS de Google Closure Compiler

He estado revisando el compilador de cierre de Google recientemente. Descargué el archivo .jar y lo probé. Hasta ahora, debo decir que me ha impresionado mucho. Ciertamente puedo ver su utilidad más allá de la minimización. ¡Apoyos al equipo de Google!

Sin embargo, tengo una pequeña queja. Me parece que solo tienes dos opciones en lo que respecta a la optimización. Es SIMPLE_OPTIMIZACIONES u ADVANCED_OPTIMIZACIONES. El primero, aunque adecuado, es muy simple en mi humilde opinión. Por un lado, a menos que me esté perdiendo algo, deja intactos todos los nombres de propiedad. Tampoco elimina el código inalcanzable. Por otro lado, la última opción es simplemente demasiado destructiva.

Ahora, soy bastante nuevo en JavaScript, por lo que es muy probable que me esté perdiendo algo. Si digo algo estúpido, siéntete libre de educarme. Dicho esto, puedo entender los problemas con el cambio de nombre en JavaScript. El equipo de Google recomienda usar la notación de corchetes (objeto['propiedad']) en lugar de la notación de puntos (objeto.propiedad) para acceder a las propiedades que no desea cambiar y nunca mezclar los dos usos. También sugieren métodos de "exportación" utilizando el siguiente patrón:

MyClass = function(name) {
  this.myName = name;
};

MyClass.prototype.myMethod = function() {
  alert(this.myName);
};

window['MyClass'] = MyClass; // <-- Constructor
MyClass.prototype['myMethod'] = MyClass.prototype.myMethod;

Sin embargo, hay casos legítimos en los que desea mezclar las dos notaciones. Digamos que estamos construyendo un juego. El código del juego está completamente aislado dentro de un cierre. No 'exporta' nada al ámbito global, ni necesita hacerlo. De hecho, realmente no debería tocar el objeto de la ventana. De todos modos, eso sí necesita leer algunas propiedades del juego de los archivos de configuración XML.

Ejemplo de JavaScript:

var TheGreatAdventure = (function(window) {

    function Fighter() {
        // Private to application
        this.id        = 42;
        // Accessible to XML configuration system
        this.name      = 'Generic Jen';
        this.hitPoints = 100;
        this.onAttack  = genericFighterAttack;
        this.onSpeak   = genericFighterSpeak;
        ...
    }
    Fighter.publishedProperties = ['name', 'hitPoints', 'onAttack', 'onSpeak']

    function genericFighterAttack() {...}
    function genericFighterSpeak() {...}

    function cassieAttack() {...}
    function cassieSpeak() {...}

    ...

    EntityReader = {
        ...
        function readFromXMLNode(attributes, entityClass, entityInstance) {
            for (var i = 0; i < attributes.length; i++) {
                var attribute = attributes[i];
                if (attribute.nodeName in entityClass.publishedProperties)
                    entityInstance[attribute.nodeName] = bindContext[attribute.value];
            }
        }
        ...
    }

}(window));

Ejemplo de archivo de configuración XML:

<Fighter name='Custom Cassie' onAttack='cassieAttack' onSpeak='cassieSpeak'/>

¡El sistema anterior no solo fallaría en asignar las propiedades, sino que las funciones cassieAttack y cassieSpeak se habrían eliminado durante la minimización como código muerto!

Ahora, no hay forma de que acceda a todas las propiedades 'publicadas' usando la notación de paréntesis en todo el código del juego. Incluso si no hay una penalización de tiempo de ejecución al hacerlo (no debería haber ninguna), todavía hay mucho tipeo adicional involucrado y es (en mi opinión) una monstruosidad. Con propiedades tan comunes, todo se mostraría como una cadena dentro de un editor de texto, ¡lo que anularía el propósito del resaltado de sintaxis!

Me parece que una simple directiva @preserve (o algo similar) sobre esas propiedades permitiría usar ADVANCED_OPTIMIZATIONS con un costo mínimo en el tamaño final del programa. ¿Me estoy perdiendo de algo?