You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, optimization strategies are specified by an import, such as:
importscalaxy.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:
importscalaxy.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.
The text was updated successfully, but these errors were encountered:
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?)
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.
Currently, optimization strategies are specified by an import, such as:
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:
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.
The text was updated successfully, but these errors were encountered: