Open lgassman opened 7 years ago
There is probably a first bug (NPE) while trying to show an error. Then the error itself. I guess that it is that it tried to execute an abstract method.
Now besides that, there is a semantic decision here. Basically this shows that today you can come up with a hierarchy chain like this (regarding method overwrite)
concrete <--- abstract <--- concrete( with super)
The question are
The latest is actually an idea that we have been discussing for some time when defining mixins. m1() in Mixin2 could be thought as a "method requirement". And not as "I'm defining a method". So in that "sense" it shouldn't be taken into account for the lookup. One solution would be to differentiate this ideas syntactically:
mixin Mixin2 {
requires method m1() // this is not a method definition, just a constrain
method m5() // should we still allow abstract methods definitions ?
}
None of this approaches have relative common ideas on other industrial languages, I guess. But it shouldn't matter if they are consistent. Scala for examples introduces also their not-so-natural ideas like the fact that a mixin can extends a class or a mixin, or "abstract override" keywords o typing "this". They are all cases to impose requirements over where the mixin can be combined.
I kind of like the scala semantics in this point. When I have a mixin with abstract m1 it should be read "I must be installed in an object with a defined m1". We should not care if it is after or before in the hierarchy. I think it is very powerful.
This leads to several cases. Following Leo's code
object x = new SuperClass mixed with M1 // Ok object y = new Object mixed with M1 // Not ok, Object does not define m1() object z = new Object mixed with M1, M2 // Ok, M2 fills the requierement.
class C extends Object mixed with M1 {} // Also ok, but C is an abstract class
I think that we can avoid having two different cases:
requires method m1() // this is not a method definition,
just a constrain
method m5() // should we still allow abstract
methods definitions ?
We could have just one, you have a requirement and you do not care where it is fullfilled.
On Sat, Oct 1, 2016 at 4:02 PM, javierfernandes notifications@github.com wrote:
There is probably a first bug (NPE) while trying to show an error. Then the error itself. I guess that it is that it tried to execute an abstract method.
Now besides that, there is a semantic decision here. Basically this shows that today you can come up with a hierarchy chain like this (regarding method overwrite)
concrete <--- abstract <--- concrete( with super)
The question are
- Should we consider the abstract as meaning "I'm cancelling the method implementation forcing subclasses to implement" ?
- If "yes", then I guess that the hierarchy should be detected as invalida, but just because of using "super" in a mixin, having an abstract impl as the first super.
- It could be "no" then it could be at least two cases: 1) just ignoring the abstract method in the lookup (which seems also weird), 2) analyze the "abstract method declaration" REAL INTENTION in the mixin.
The latest is actually an idea that we have been discussing for some time when defining mixins. m1() in Mixin2 could be thought as a "method requirement". And not as "I'm defining a method". So in that "sense" it shouldn't be taken into account for the lookup. One solution would be to differentiate this ideas syntactically:
mixin Mixin2 {
requires method m1() // this is not a method definition, just a constrain method m5() // should we still allow abstract methods definitions ?
}
None of this approaches have relative common ideas on other industrial languages, I guess. But it shouldn't matter if they are consistent. Scala for examples introduces also their not-so-natural ideas like the fact that a mixin can extends a class or a mixin, or "abstract override" keywords o typing "this". They are all cases to impose requirements over where the mixin can be combined.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1002#issuecomment-250914054, or mute the thread https://github.com/notifications/unsubscribe-auth/AEa1OQW21g0lAV5ofMC3e4P5Zf1zrPJKks5qvmfygaJpZM4KLiDF .
See this example:
REPL history: