I have three Groovy classes: M, A, & B. B exists as a mixin of M and an extension of the abstract class A:
class M {
def foo = 11
def bar = 12
}
abstract class A {
abstract foo
}
#Mixin(M)
class B extends A {
}
def b = new B()
print "${b.foo}\n"
print "${b.bar}\n"
Attempting to run this causes Groovy to complain with:
Can't have an abstract method in a non-abstract class. The class 'B' must be declared abstract or the method 'void setFoo(java.lang.Object)' must be implemented.
However, the method is implemented by the mixin M.
Furthermore, if I change B to be:
#Mixin(M)
class B extends A {
def foo = 13
}
Then I get the printout:
11
12
And not:
13
12
Which is what I expect and seems to prove that M provides an acceptable implementation of the abstract methods of A.
So, why isn't groovy happy with using the mixin M to satisfy the abstract class A, what am I doing wrong?
You're doing nothing wrong. It's the problem of the compiler performing this check before actually applying the AST transformations. You better post this on their issue tracker at http://jira.codehaus.org/secure/BrowseProject.jspa?id=10242.
Since #Mixin transformation was actually created by the author of Groovy++ AFAIK, and since Groovy++ has much more extended support for categories, mixins and traits you could expect this to be a valid code there. You should try it.
Related
I have a superclass called A and a subclass called B that inherits from A. The superclass's constructor looks like this:
A(String name, char displayChar, int hitPoints, Behaviour behaviour)
{
this.name = name;
this.displayChar = displayChar;
this.hitPoints = hitPoints
addBehaviour(behaviour);
}
A has attributes of name, displayChar, hitPoints, behaviour and has a method that calls addBehaviour which adds the behaviour to the object.
The subclass, B's constructor looks like this:
B(String name) {super(name, char 'b', 10, new WalkBehaviour()); }
Now my question is, does subclass B have an attribute of WalkBehaviour?
How would the UML diagram look like for this scenario? I know B inherits from A and A has Behaviour but does B has WalkBehaviour in this case? Since B doesn't have an instance variable of type WalkBehaviour in its class but only passes WalkBehaviour through its superclass's constructor.
does subclass B have an attribute of WalkBehaviour?
No. There is none declared. The superclass will do something with that new object but obviously it's hidden in the mist of its implementation.
Inheritance is nothing that involves multiple object creation. Your B instance is just a single one which does have attributes and operations like its super class.
Thus, in a SD, you will see only one life line for B:
As you can see the B instance will just issue a self-call to the super class's constructor.
Note: as #AxelScheithauer pointed out in the comment the super class will invoke addBehavior which can (but must not) be shown in the SD:
I find in Kotlin: Object documentation an example:
open class A(x: Int) {
public open val y: Int = x
}
interface B {...}
val ab: A = object : A(1), B {
override val y = 15
}
So I implemented that example with more meaningful names and I have no clue what is the reason of the interface among the comma separated list of supertypes to the object?
interface Toy {
fun play () {
println("Play, play....")
}
}
open class Ball(public open val color: String = "red") {}
val ball: Ball = object : Ball(), Toy {
override val color : String = "blue"
override fun play() {
println("Bounce, bounce...")
}
}
fun main(args: Array<String>) {
println(ball.color)
// no ball.play() here then why the interface in the example ???
}
You're correct, the interface B (or in your example, Toy) will not be directly accessible through this reference if A (or Ball) doesn't implement it.
Inheriting from that interface is probably just added here so that this example intended to show how constructor parameters are passed to a superclass can also show off inheriting from multiple types very quickly. Or at least that's what I gather from the text accompanying it:
If a supertype has a constructor, appropriate constructor parameters must be passed to it. Many supertypes may be specified as a comma-separated list after the colon.
To get to the issue of not being able to use the created object as a B (or Toy) here: this doesn't make the language feature useless, since the created object can still be used through its multiple interfaces through casting. For example, in your example, you can do this:
(ball as Toy).play()
Or in the original example, you could make the type Any, and then cast to the different interfaces as needed.
You have created an instance of an anonymous class that inherits from class Ball and at the same time implements interface Toy.
But, both of these types are exclusive, ie. Ball is not a Toy (in your example), so you cannot call play() on a reference to Ball.
This Groovy script runs fine:
println 0;
class MyClass
{
public MyClass(int j) {};
public MyClass method() {return this};
}
This one fails with a compilation error ("unexpected token: public at line: 5, column: 4")
println 0;
class myClass
{
public myClass(int j) {};
public myClass method() {return this};
}
The only difference is the capitalization of the class name. I know the convention is for class names to be capitalized, but I thought it was just a convention. What exactly causes the compile error?
According to a Groovy mailing list thread from 2008, where a similar question was posed, Paul King explained:
Yes, the grammar currently looks for uppercase types only in declarations (apart from the primitive types).
In a more recent, unresolved Groovy JIRA ticket regarding lowercase class names, blackdrag comments that:
The problem is that in Groovy (unlike Java) variable names, method names and class names can share a context, making it ambiguous.
Barring a deeper exploration of the tokenizer, I'll just chalk this up as another minor inconsistency between Java and Groovy due to Groovy's syntax flexibility. And instead of thoroughly implementing a way to tell if a token is a type or method name in this context, Groovy takes a short cut and only assumes it can be a type name if the token matches a primitive or begins with a capital letter, as conventional Java types would.
I have a generic class:
public abstract class ModelSet<T> : ObservableCollection<T>, IModelObject where T : ModelObject, new(){
public static ModelSet<T> Lookup(long pObjectId){
return (ModelObjectMap.Get(pObjectId) as ModelSet<T>);
}
}
I have the following class instantiation of the type using a class Movement defined as:
class Movement : ModelObject.
public partial class Movements : ModelSet<Movement>
The following code won't compile due to
cannot implicitly convert type ModelSet<Movement> to Movements. An explicit conversion exists.
Movements X = Movements.Lookup(12345);
Surely, they are the same. What am I doing wrong?
Surely, they are the same.
No, they're not the same. One is Movements, and the other is ModelSet<Movement>. While every Movements instance is an instance of ModelSet<Movement>, it's entirely possible to have a ModelSet<Movement> which isn't a Movements... and your method's return type only says that it will return a ModelSet<T>.
We have no idea what ModelObjectMap.Get(pObjectId) actually does, but it could definitely return a ModelSet<Movement> instance which isn't a Movements.
We don't know what you need to do with the return value, but you could certainly write:
ModelSet<Movement> X = Movements.Lookup(12345);
... although it's worth noting that the Movements class actually isn't involved in that call at all; it would actually be compiled to:
ModelSet<Movement> X = ModelSet<Movement>.Lookup(12345);
I am trying to understand type members in Scala. I wrote a simple example that tries to explain my question.
First, I created two classes for types:
class BaseclassForTypes
class OwnType extends BaseclassForTypes
Then, I defined an abstract type member in trait and then defined the type member in a concerete class:
trait ScalaTypesTest {
type T <: BaseclassForTypes
def returnType: T
}
class ScalaTypesTestImpl extends ScalaTypesTest {
type T = OwnType
override def returnType: T = {
new T
}
}
Then, I want to access the type member (yes, the type is not needed here, but this explains my question). Both examples work.
Solution 1. Declaring the type, but the problem here is that it does not use the type member and the type information is duplicated (caller and callee).
val typeTest = new ScalaTypesTestImpl
val typeObject:OwnType = typeTest.returnType // declare the type second time here
true must beTrue
Solution 2. Initializing the class and using the type through the object. I don't like this, since the class needs to be initialized
val typeTest = new ScalaTypesTestImpl
val typeObject:typeTest.T = typeTest.returnType // through an instance
true must beTrue
So, is there a better way of doing this or are type members meant to be used only with the internal implementation of a class?
You can use ScalaTypesTestImpl#T instead of typeTest.T, or
val typeTest:ScalaTypesTest = new ScalaTypesTestImpl
val typeObject:ScalaTypesTest#T = typeTest.returnType
If you don't want to instance ScalaTypesTestImpl, then, perhaps, you'd be better off putting T on an object instead of class. For each instance x of ScalaTypesTestImpl, x.T is a different type. Or, in other words, if you have two instances x and y, then x.T is not the same type as y.T.