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

Syntactic Prototypes #91

Open
Nathan-Wall opened this issue Sep 5, 2014 · 0 comments
Open

Syntactic Prototypes #91

Nathan-Wall opened this issue Sep 5, 2014 · 0 comments
Labels

Comments

@Nathan-Wall
Copy link
Owner

Proposal

Currently prototypes are declared by stating a base class and mixing in properties.

sym @employees;
var Manager = like Employee := #{
    @employees: nil,
    init: fn() :{
        this::Employee();
        this.@employees = [ ];
    },
    addEmployee: fn(employee) :{
        [email protected](employee);
    }
};

While it's nice the way various syntactic forms come together to produce an easily readable prototype definition without the need for special syntax, we could still stand to gain some by adding special syntax.

proto Manager like Employee {
    @employees = [ ];
    fn init() :{
        super();
    }
    fn addEmployee(employee) :{
        [email protected](employee);
    }
}

Pros

  • We could remove the way symbols mix into an object by default (transferability). foo := bar currently mixes all bar's symbol properties into foo (except for symbols explicitly declared as non-transferable). Although this could be nice in some cases, it has never quite sat well with me and could represent a leak of private data.
  • We'd have the freedom to enforce modules to only use declarative forms in the top level. This isn't currently possible because it would be common to want to export a prototype and building prototypes currently requires runtime code. Restricting module level code to declarative forms could have some benefits regarding export/import syntax and semantics, static analysis, and circular dependency management. We may not necessarily want to use this restriction or all of the possible benefits, but it at least opens up these possibilities.
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