Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

lrytz
Copy link
Member

@lrytz lrytz commented May 7, 2014

Avoid null checks for "someLiteral".== and SomeModule.==. This has
been implemented in GenICode in #2954.

Introduces a trait to share code between GenICode and GenBCode. This
is just a start, more such refactorings will come quite certainly.

Test already exists. The new scala-nightly-genbcode-2.1X.x nightly build
runs all tests on the new backend (that's how the difference was found).

Avoid null checks for "someLiteral".== and SomeModule.==. This has
been implemented in GenICode in scala#2954.

Introduces a trait to share code between GenICode and GenBCode. This
is just a start, more such refactorings will come quite certainly.
@lrytz
Copy link
Member Author

lrytz commented May 7, 2014

Review by @retronym

@retronym
Copy link
Member

retronym commented May 7, 2014

LGTM. Here's a the build failure for the record.

@retronym
Copy link
Member

retronym commented May 7, 2014

As a followup, you probably want to find the spots where I've already shared code between the backends, by having one call the other, and move that into the new common trait.

@lrytz lrytz added the reviewed label May 7, 2014
@lrytz
Copy link
Member Author

lrytz commented May 7, 2014

Right, one could also call genBCode.isNull in GenICode (or vice versa). I can change things if that is the preferred approach. Can you give me an example of such a call that you introduced?

@retronym
Copy link
Member

retronym commented May 7, 2014

i think your way is cleaner.

I did this most recently in the #3711.

Before that:

git log -i --grep duplication -- src/compiler/scala/tools/nsc/backend/
commit c7a5aab0d34243bfec9de2882594927b460b1ec9
Author: Jason Zaugg <[email protected]>
Date:   Sat Feb 15 14:30:50 2014 +0100

    SI-3452 Reduce low-hanging duplication bewteen GenASM and GenBCode

commit 6e2cadb8bd42e0f4a6c777b11ff71f92cda368e8
Author: Jason Zaugg <[email protected]>
Date:   Mon Sep 16 12:55:10 2013 +0200

    SI-7847 Static forwarders for case apply/unapply

    These were excluded in f901816b3f because at the time they
    were compiler fiction and translated to calls to the case
    class constructor or accessors.

    But since they are now bona-fide methods (albeit still occasionally
    bypassed as an optimization), we can expose them conveniently to our
    Java brethren.

    The cut-and-pastiness of GenBCode starts to hinder maintenance.
    Here's a report of further duplication that we have to fix up
    post haste: https://gist.github.com/retronym/6334389

commit 7d83be218473f08ab560c937318faadce2617d95
Author: Paul Phillips <[email protected]>
Date:   Sun Aug 25 09:22:47 2013 -0700

    Logging cleanup.

    Reduced the amount of extraneous logging noise at the
    default logging level.

    Was brought to my usual crashing halt by the discovery of identical
    logging statements throughout GenASM and elsewhere. I'm supposing
    the reason people so grossly underestimate the cost of such duplication
    is that most of the effects are in things which don't happen, aka
    "silent evidence".

    An example of a thing which isn't happening is the remainder of
    this commit, which exists only in parallel universes.

@gkossakowski
Copy link
Contributor

Would it be ok to use composition + imports instead of inheritance for code sharing?

final class BCodeICodeCommon(global: Global) {
  import global._
  // the common code
}

and then

abstract class GenICode extends SubComponent {
  private val bCodeICodeCommon = new BCodeICodeCommon(global)
  import bCodeICodeCommon._
} 

This would help incremental compilation. If you use inheritance and add something to BCodeICodeCommon then trait/class that inherits it directly or indirectly has to be recompiled. If you use composition it's most likely that nothing apart from BCodeICodeCommon will get recompiled.

@lrytz lrytz added the tested label May 7, 2014
@lrytz
Copy link
Member Author

lrytz commented May 7, 2014

Sure, that's fine with me.

@gkossakowski
Copy link
Contributor

Actually, I realized now that you'll need:

final class BCodeICodeCommon[ThisGlobal <: Global](global: ThisGlobal)

in order to push through the path-dependent types.

@lrytz
Copy link
Member Author

lrytz commented May 8, 2014

@gkossakowski ptal

@@ -30,6 +29,9 @@ abstract class GenICode extends SubComponent {
}
import platform.isMaybeBoxed

private val bCodeICodeCommon: jvm.BCodeICodeCommon[GenICode.this.global.type] = new jvm.BCodeICodeCommon(global)
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't global.type enough?

@lrytz lrytz removed the tested label May 8, 2014
@lrytz
Copy link
Member Author

lrytz commented May 8, 2014

done, thanks

@gkossakowski
Copy link
Contributor

LGTM

@lrytz lrytz added the tested label May 8, 2014
retronym added a commit that referenced this pull request May 8, 2014
@retronym retronym merged commit 972244d into scala:2.11.x May 8, 2014
@lrytz lrytz deleted the t7852 branch May 10, 2014 07:08
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