[ https://issues.apache.org/jira/browse/GROOVY-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Allen Arakaki updated GROOVY-7441: ---------------------------------- Description: This issue was created to attach files to this bug: https://issues.apache.org/jira/browse/GROOVY-7416 @CompileStatic should compile the following: {code} abstract class ABaseClass implements SomeInterface, SomeTrait, TraitWithSomeOtherInterface { } abstract class ASubClass extends ABaseClass { void someMethod() { someInterfaceMethod() someTraitMethod() someOtherInterfaceMethod() } } interface SomeInterface { void someInterfaceMethod() } interface SomeOtherInterface { void someOtherInterfaceMethod() } trait SomeTrait { abstract void someTraitMethod() } trait TraitWithSomeOtherInterface implements SomeOtherInterface { } {code} Now that I've had time to think about this some more, the above isn't complete because there's an infinite number of possibilities with traits: 1) traits can extend other traits. For example, trait A extend B { } trait B extend C { } ... etc 1) traits can implement other traits/interfaces. For example, trait A implements B, C, D { } trait B extend E { } trait C implements F { } ... and so on The main value of traits, aside from (implementation w/ interface) is the behavior of "stackable traits." So as long as we can get that to work, then all other permutations aren't as important imho. For example: {code} ABaseClass implements TraitA, TraitB, TraitC { } ASubClass extends ABaseClass { someMethod() { doSomething() // this method is equivalent to calling TraitC.super.doSomething(), then TraitB.super.doSomething(), then TraitA.super.doSomething() } } interface IDoSomething { void doSomething() } trait TraitA implements IComparable { void doSomething() { if (forA) { // call for us } else { // pass the call on try { // we wrap this in try/catch because we won't assume the implementation order super.doSomething() } catch(e) { } } } } trait TraitB implements IComprable { if (forB) { // call for us } else { // pass the call on try { // we wrap this in try/catch because we won't assume the implementation order super.doSomething() } catch(e) { } } } trait TraitC implements IComprable { if (forC) { // call for us } else { // pass the call on try { // we wrap this in try/catch because we won't assume the implementation order super.doSomething() } catch(e) { } } } {code} was: This issue was created to attach files to this bug: https://issues.apache.org/jira/browse/GROOVY-7416 @CompileStatic should compile the following: {code} abstract class ABaseClass implements SomeInterface, SomeTrait, TraitWithSomeOtherInterface { } abstract class ASubClass extends ABaseClass { void someMethod() { someInterfaceMethod() someTraitMethod() someOtherInterfaceMethod() } } interface SomeInterface { void someInterfaceMethod() } interface SomeOtherInterface { void someOtherInterfaceMethod() } trait SomeTrait { abstract void someTraitMethod() } trait TraitWithSomeOtherInterface implements SomeOtherInterface { } {code} > Problem With CompileStatic And Trait Methods In Abstract Subclass > ----------------------------------------------------------------- > > Key: GROOVY-7441 > URL: https://issues.apache.org/jira/browse/GROOVY-7441 > Project: Groovy > Issue Type: Bug > Components: Compiler > Affects Versions: 2.4.3 > Reporter: Allen Arakaki > Attachments: abstractcompilestatic.zip > > > This issue was created to attach files to this bug: > https://issues.apache.org/jira/browse/GROOVY-7416 > @CompileStatic should compile the following: > {code} > abstract class ABaseClass implements SomeInterface, SomeTrait, > TraitWithSomeOtherInterface { > } > abstract class ASubClass extends ABaseClass { > void someMethod() { > someInterfaceMethod() > someTraitMethod() > someOtherInterfaceMethod() > } > } > interface SomeInterface { > void someInterfaceMethod() > } > interface SomeOtherInterface { > void someOtherInterfaceMethod() > } > trait SomeTrait { > abstract void someTraitMethod() > } > trait TraitWithSomeOtherInterface implements SomeOtherInterface { > } > {code} > Now that I've had time to think about this some more, the above isn't > complete because there's an infinite number of possibilities with traits: > 1) traits can extend other traits. For example, > trait A extend B { > } > trait B extend C { > } > ... etc > 1) traits can implement other traits/interfaces. For example, > trait A implements B, C, D { > } > trait B extend E { > } > trait C implements F { > } > ... and so on > The main value of traits, aside from (implementation w/ interface) is the > behavior of "stackable traits." So as long as we can get that to work, then > all > other permutations aren't as important imho. For example: > {code} > ABaseClass implements TraitA, TraitB, TraitC { > } > ASubClass extends ABaseClass { > someMethod() { > doSomething() // this method is equivalent to calling > TraitC.super.doSomething(), then TraitB.super.doSomething(), then > TraitA.super.doSomething() > } > } > interface IDoSomething { > void doSomething() > } > trait TraitA implements IComparable { > void doSomething() { > if (forA) { > // call for us > } else { > // pass the call on > try { // we wrap this in try/catch because we won't assume the > implementation order > super.doSomething() > } catch(e) { > } > } > } > } > trait TraitB implements IComprable { > if (forB) { > // call for us > } else { > // pass the call on > try { // we wrap this in try/catch because we won't assume the > implementation order > super.doSomething() > } catch(e) { > } > } > } > trait TraitC implements IComprable { > if (forC) { > // call for us > } else { > // pass the call on > try { // we wrap this in try/catch because we won't assume the > implementation order > super.doSomething() > } catch(e) { > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)