Skip to content

Test demonstrating extension method shorthands #6339

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

Merged
merged 2 commits into from
Apr 19, 2019

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Apr 18, 2019

This test shows that the overhead of extension methods can be reduced
to be no more than 7 characters per method, using two tricks:

  • Any implicit parameters become parameters of the enclosing implied instance
  • A local type alias can be used to abbreviate the (repetitive) first parameter
    string.

This demonstration strengthens the case for the current syntax for extension methods.

This test shows that the overhead of extension methods can be reduced
to be no more than 7 characters per method, using two tricks:

 - Any implicit parameters become parameters of the enclosing implied instance
 - A local type alias can be used to abbreviate the (repetitive) first parameter
   string.

This demonstration strengthens the case for the current syntax for extension methods.
@odersky odersky force-pushed the add-extmethod-test branch from 7f3f5c6 to eefe66f Compare April 18, 2019 13:54

implied StringListOps given TC {
type T = List[String]
def (x: T) foo (y: T) = (x ++ y, the[TC])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an interesting trick, but I'm afraid that it'll make signature information less readable in error messages and in the IDE (e.g. if I'm writing a.foo(, then a signature popup will tell me that an argument of type T is expected), and dealiasing all the time before showing type information is likely to be even less readable in general.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, in practice it would probably be named This or Self or Left, not T. And of course we should have defined foo like this:

def (x: T) foo (y: List[String]) = ...

Then the signature popup gives you the right info again.

@odersky odersky merged commit 4d56be3 into scala:master Apr 19, 2019
@allanrenucci allanrenucci deleted the add-extmethod-test branch April 19, 2019 17:20
@milessabin
Copy link
Contributor

Nice trick. I'll give it a try.

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

Successfully merging this pull request may close these issues.

3 participants