royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Private API names
Date Wed, 31 Oct 2018 16:21:27 GMT
Hi Kenny,

I went and made the changes to decorate private variable names.  I made it an option that's
on by default.  IMO, it makes debugging the framework really painful.  I'm probably going
to turn the flag off in the framework and have a policy that we don't use the same private
variable names.  It shouldn't affect what users do.

Also, turning the option off revealed a fair amount of duplicated code.  Sometimes we copy
a file to form the basis of a subclass and then don't clean up everything and you don't find
out about private methods if they have their names decorated.

-Alex

´╗┐On 10/28/18, 5:22 AM, "Kenny Lerma" <kenny@kennylerma.com> wrote:

    Alex, this is absolutely needed.  The same private variables names in base
    class and subclass are quite common.  Since this only affects debug, there
    is no harm in the decorator and maintains consistency with flash.
    
    
    On Sat, Oct 27, 2018, 9:05 PM Alex Harui <aharui@adobe.com.invalid> wrote:
    
    > Hi,
    >
    > It appears that in Flash, private variables are actually in a custom
    > namespace.  This means you can have private APIs in a base class and
    > private APIs in a subclass with the same name (and aren't overrides) and
    > everything "works".  IOW:
    >
    > package org.apache.royale.core {
    > public class BaseClass {
    >    private var foo:String = "foo,";
    >    public function BaseClass() {
    >       trace(foo);
    >    }
    > }}}
    >
    > package org.apache.royale.core {
    > public class MyClass {
    >    private var foo:String = "bar!";
    >    public function MyClass() {
    >       super();
    >       trace(foo);
    >    }
    > }}}
    > 
    > var baz:MyClass = new MyClass();  // outputs foo,bar!
    >
    > This is true for private functions and getters/setters as well.  However,
    > this currently does not work in JS, since the transpiled code looks like:
    >
    > org.apache.royale.core.BaseClass = function() { trace(this.foo) }
    > org.apache.royale.core BaseClass.prototype.foo = "foo,";
    >
    > And
    >
    > org.apache.royale.core MyClass = function() { trace(this.foo} }
    > org.apache.royale.core MyClass.prototype.foo = "bar!";
    >
    > So you will get "bar!bar!";
    >
    >
    > The MX Charts code uses the same private API names in base classes and
    > subclasses.  I don't know why they didn't use protected methods and
    > override them, so I'm going to change the Charts code to use overrides just
    > to keep making progress.
    >
    > I'm wondering if anybody else uses the same private API name in base
    > classes and subclasses.  The theoretical fix is to have the compiler
    > generate a decorated name.  That's what the compiler already does for
    > mx_internal APIs and other custom namespace APIs, but I think it would make
    > our code fatter and uglier to decorate private API names, so I'm tempted to
    > have the compiler emit an error or warning instead.
    >
    > In order to guarantee uniqueness, we'd have to decorate with the fully
    > qualified name of the class.  Then the transpiled code would look like:
    >
    > org.apache.royale.core.BaseClass = function() {
    > trace(this.org_apache_royale_core_BaseClass_foo) }
    > org.apache.royale.core
    > BaseClass.prototype.org_apache_royale_core_BaseClass_foo = "foo,";
    >
    > And
    >
    > org.apache.royale.core MyClass = function() {
    > trace(this.org_apache_royale_core_MyClass_foo} }
    > org.apache.royale.core
    > MyClass.prototype.org_apache_royale_core_MyClass_foo = "bar!";
    >
    > IMO, that's a painful change to the transpiler, so I want to make sure we
    > really need to do this.  I think it won't impact minified size, but it will
    > be noticeable when debugging the JS.
    >
    > Thoughts?
    > -Alex
    >
    >
    >
    

Mime
View raw message