[
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)
