Skip to content

Should we do infix :: instead of private methods (and other things)? #38

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

Open
erights opened this issue Mar 16, 2018 · 5 comments
Open

Comments

@erights
Copy link
Collaborator

erights commented Mar 16, 2018

See tc39/proposal-pipeline-operator#107

@erights
Copy link
Collaborator Author

erights commented Mar 16, 2018

For :: to do the job of -> for hidden methods, we'd replace the hidden method declaration with a lexical function declaration as previously proposed. The first hidden method example at
https://github.com/zenparsing/js-classes-1.1#2-hidden-methods
becomes

class Spaceship {
  function flyTo(destination) {
    // Blast off!
  }

  flyToMoon() {
    this::flyTo(Location.MOON);
  }
}

@zenparsing
Copy link
Owner

@erights Using this approach, what would instance var references look like?

@bathos
Copy link

bathos commented Mar 16, 2018

I rather like this — when I need private methods currently, I do exactly this but with .call() (and function declarations outside the body, obviously).

One q: if the syntax is function flyTo() {}, it suggests to me flyTo would be created with a [[construct]] slot and without a home object. What would actually occur?

@zenparsing
Copy link
Owner

if the syntax is function flyTo() {}, it suggests to me flyTo would be created with a [[construct]] slot and without a home object. What would actually occur?

Presumably, that's how it would work. That points to my main concern: that we would have two similar-but-different function definition forms inside of class bodies.

@erights I think I understand your concern: hidden methods are (more-or-less) just extension methods. But extension methods are useful generally, not just inside of class bodies. Shouldn't we try to think of a solution that works everywhere?

Is that what you're thinking?

🤔

@zenparsing
Copy link
Owner

@erights Just kicking some ideas around, purely for fun:

What if we had an extension declaration form:

'extension' '{' MethodDefinition* '}'

For example:

extension {
  x() {}
  get y() {}
}

This declaration form would introduce "hidden" bindings into the enclosing scope in a parallel namespace (similar to the way our current hidden methods work).

Using an extension accessor:

extension {
  get fullName() {
    return this.first + ' ' + this.last;
  }
}

({ first: 'Kevin', last: 'Smith' })::fullName; // 'Kevin Smith'

Extension declarations would also be allowed inside of classes:

class Person {
  constructor() {
    this.first = 'Kevin';
    this.last = 'Smith';
  }

  sayHello() {
    return `Hi, I'm ${ this::fullName }`;
  }

  extension {
    get fullName() {
      return this.first + ' ' + this.last;
    }
  }
}

Then I suppose that instance var references would be rationalized as automatically generated extension accessors within the class body.

I have no idea how you'd import and export these things, though 🙄

Again, just playing around for fun!

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

No branches or pull requests

3 participants