Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

work around naming conflicts for private class members #4

Closed
jvasileff opened this issue Dec 4, 2015 · 5 comments
Closed

work around naming conflicts for private class members #4

jvasileff opened this issue Dec 4, 2015 · 5 comments
Labels
Milestone

Comments

@jvasileff
Copy link
Owner

Dart "private" members of classes are polymorphic, at least within the same package. Ceylon non-shared members are not; a private member may shadow, but not override a super class member of the same name.

So we need some way to distinguish Super.x from Sub.x. The easiest (only?) approach may be to use globally (or at least module-wide) unique names for private members. This isn't a problem for interfaces since static invocation is always used for non-shared interface members.

The code below currently prints "B B" rather than "A B":

shared void run() {
    class A() {
        String id => "A";
        shared String idA => id;
    }
    class B() extends A() {
        String id => "B";
        shared String idB => id;
    }
    print(B().idA); // should print "A"
    print(B().idB); // should print "B"
}

the problem can also occur with outer in a recursive member class:

shared void run() {
    class C() {
        String id => "C";
        shared class D() extends C() {
            String id => nothing;
            shared String outerId => outer.id;
        }
    }
    print(C().D().D().outerId); // should print "C", not crash on `nothing`
}

or on invocation of a static reference:

shared void run() {
    class E() {
        String id => "E";
        shared class F() extends E() {
            String id => nothing;
            shared String eId => E.id(this);
        }
    }
    print(E().F().eId); // should print "E", not crash on `nothing`
}
@jvasileff jvasileff added the bug label Jan 23, 2016
@jvasileff
Copy link
Owner Author

Also need to review all synthetic "fields" (for things like forward declared methods) to make sure they have unique names.

@jvasileff
Copy link
Owner Author

Reopening. Still need to review synthetic fields.

@jvasileff jvasileff reopened this Aug 28, 2016
@jvasileff jvasileff added this to the DP3 milestone Aug 28, 2016
@jvasileff
Copy link
Owner Author

This works:

shared void run() {
    class C() {
        String foo();
        foo = () => "C";
        shared String fooValueC => foo();
    }
    class D() extends C() {
        String foo();
        foo = () => "D";
        shared String fooValueD => foo();
    }
    assert(D().fooValueC == "C");
    assert(D().fooValueD == "D");
}

because the synthetic names are based on the unique private member names.

@jvasileff
Copy link
Owner Author

jvasileff commented Aug 28, 2016

This currently works:

shared void runBug4c() {
    class C() {
        shared String foo();
        foo() => "hello C";
    }
    class D() extends C() {
        String foo();
        foo() => "hello D";
    }
    assert (C().foo() == "hello C");
}

but somewhat by chance. The synthetic Callable for C.foo is foo$c, but really should be private, like _foo$c. And D.foo's variable is _$foo$c because foo is named _$foo, but that could possibly change in #25.

Edit: Indeed, _$foo$c is now _foo$c. So #26 will have to account for this.

jvasileff added a commit that referenced this issue Aug 28, 2016
These tests focus on synthetic variables, for #4
@jvasileff
Copy link
Owner Author

Tests added. Fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant