Uploaded image for project: 'Groovy'
  1. Groovy
  2. GROOVY-5989 Inner Class Issues
  3. GROOVY-3714

"groovy" command line program doesn't resolve inner classes properly when they're in another file

    XMLWordPrintableJSON

Details

    • Sub-task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.7-beta-1
    • None
    • None

    Description

      Martin C. Martin schrieb:
      > Foo.groovy:
      >
      > class Foo {
      > static class Bar

      { > static float yum = 3.5 > }

      > }
      >
      > Test.groovy:
      >
      > println Foo.Bar.yum
      >
      > > rm Foo*class Test*class
      >
      > > groovy Test

      hmm... in one file it works... uh oh... I get a bad feeling... I think it is because ResolveVisitor finds Foo to be a class and then queues Foo, but wrongly assumes that it is done then. So Test.groovy is completed before Foo.groovy is parsed, meaning Foo will be recognized as class, but Foo.Bar will not.

      > > groovyc Test
      >
      > > groovy Test
      >
      > 3.5

      "groovy Test" does not run the class file, it runs the groovy file. That means it is equal to compiling Foo.groovy and then compiling Test.groovy. If you had given both files to the compiler, this would also work.

      [...]
      > JIRA?

      yes, but I wonder how to resolve the issue. Because if I am right we have a problem here. Normal compilation as done with eclipse or groovyc should not be affected, since you there compiler usually all files and not let the compiler pick them up.

      I could of course say, that if a file is picked up, we have to resolve the file again, but that would probably very bad for performance. Hmm.. or not, if the cache is kept... the caches saves misses as well... we only would have to go through all of the AST again and potentially remove noClass entries for Foo.Bar. Or I save the path and stop the compiler there, to let it continue later... only that this is a functionality that does exist only in my fantasy yet... I miss continuations here somehow

      Attachments

        Activity

          People

            emilles Eric Milles
            mcspanky Martin C. Martin
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: