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

Feature request: support for specifying the strategy on a per local-surgery basis #9

Open
andrewdbate opened this issue Jul 23, 2015 · 2 comments

Comments

@andrewdbate
Copy link

Currently, optimization strategies are specified by an import, such as:

import scalaxy.streams.strategy.safer

However, this results in all optimizations in scope being performed using the same strategy. Usually, this either means all optimizations in the same file have the same strategy applied, or you have lots of imports in local scopes (e.g., within methods) .

What’s more, both the Eclipse and IntelliJ plugins for Scala have an imports cleanup tool that automatically remove unused imports. You would not expect that running this tool would change the semantics of your code, but with strategies specified this way, it can.

Although Scala language features can be turned on with imports, the IDE tools have support for this, and thus do not remove such imports (and even if they did, you would get compile time errors or warnings). In all likelihood, given the current rate of plugin development for Scala, it is unlikely that the Scala plugins will support Scalaxy strategy imports any time soon.

Therefore, I would like to suggest that strategies can be additionally specified as follows:

optimize (safer) {
   // code goes here
}

That way, the IDE can never mess anything up. Also, if you specify the strategy at the local surgery site, then this should override the strategy imported (if any). This would allow you to write things like:

import scalaxy.streams.strategy.foolish
optimize {
  // Code here
}
…
optimize (safer) {
   // More code here
}
…
optimize {
   // Even more code here
}

I believe that since the semantics depends on the strategy used, it is quite important to have the strategy specified as close as syntactically possible to where local surgery is performed.

@ochafik
Copy link
Member

ochafik commented Sep 30, 2015

Oh, interesting!
Not sure we can have optimize(block) and optimize(strategy)(block) overloads, but an optimizeAs(safer)(block) sounds quite possible...

(btw I'm curious, which rewrites are you avoiding / seeking with these mixed strategies?)

@andrewdbate
Copy link
Author

I can't quite remember anymore why I was using mixed strategies within the same file, but I don't think I am anymore. It may have been to avoid an old bug when case classes were used in the pattern of a filter, although I could be wrong.

I usually use the most aggressive strategy available to avoid the generation of closures, and IntelliJ is very good at cleaning up my "unused" imports, thus reverting to the safe strategy if I'm not paying close attention.

Therefore, I would personally much rather write optimizeAs(strategy) { ... } everywhere to avoid this problem at all costs.

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

No branches or pull requests

2 participants