I have the following scenario
public abstract ClassA{
public virtual void Initialize(string a, int b){
}
}
public abstract ClassB : ClassA{
public virtual int Initialize(string a, int b){
}
}
When I try to create stub for Class B, I receive the error saying that SClassB already defines a member called 'Initialize' with the same parameter types.
How do I resolve the issue?
Thanks,
Sathish
As far as I know, you can not override within an abstract class so you would either need to lose the abstract/virtual and use override modifier on ClassB, or override it in the class(es) that inherits from ClassB.
Related
abstract class Ainterface {
String? name;
List<Binterface?>? list;
}
abstract class Binterface {
String? age;
int? len;
}
class ObjA extends Ainterface {
String? name;
List<ObjB?>? list;
ObjA({this.name, this.list});
}
class ObjB extends Binterface {
String? age;
int? len;
ObjB({this.age, this.len});
}
I used objb as the type of each item in the list, but the editor gave an error 'obja. List =' ('void function (list < objb? >?)) isn't a valid override of 'Ainterface.list=' ('void Function(List<Binterface?>?)').
How I can solve this problem?
Fields (data members) in Dart implicitly provide getters and setters as part of the interface. Therefore when you write:
abstract class Ainterface {
List<Binterface?>? list;
}
The interface is implicitly:
abstract class Ainterface {
List<Binterface?>? get list;
set list(List<Binterface?>? value);
}
The problem is that your derived class wants to provide an interface:
class ObjA extends Ainterface {
List<ObjB?>? get list;
set list(List<ObjB?>? value);
}
Even though List<ObjB?>? is substitutable for List<Binterface?>?, the reverse is not true: List<Binterface?>? is not substitutable for List<ObjB?>?, and that's the direction that matters for the setter.
The list setter in ObjA is not a safe override of the corresponding setter from Ainterface because it would allow callers to violate its contract. Ainterface.list advertises that it allows being set to any instance of a Binterface, but ObjA.list expects only an instance of ObjB. As a concrete example, if the override were allowed, then the following code would compile without error:
class AnotherB extends Binterface {}
void main() {
Ainterface a = ObjA();
a.list = [AnotherB()]; // This error would not be caught at compile-time.
}
And now a.list contains a List<AnotherB> even though ObjA.list expects List<ObjB>, and you'd eventually get an error at runtime if you try to use a.list as a List<ObjB>.
If you can logically guarantee that the above scenario will never happen, then you can use the covariant keyword to relax static type-checking and allow the override:
abstract class Ainterface {
covariant List<Binterface?>? list;
}
but I re-emphasize that the above code removes some type-safety. By using the covariant keyword, you take responsibility for ensuring that you do not violate the contract in practice.
Alternatively:
Reconsider if your abstract base class needs to expose setters as part of its interface, and expose only getters if possible.
Make Ainterface a generic class parameterized on the concrete type of Binterface:
abstract class Ainterface<DerivedB extends Binterface> {
List<DerivedB?>? list;
}
class ObjA extends Ainterface<ObjB> {
List<ObjB?>? list;
}
I'll also point out that overriding fields is usually a bad idea, and you usually should be explicitly overriding getters and setters anyway.
In the Ainterface abstract class you declared that a list should be declared of type Binterface so any class extending that class should do that. so when you want to declare a class extending this class you should consider that. if you want to also declare a list from type ObjB you can do it after that. it will be like this:
class ObjA extends Ainterface {
String? name;
List<Binterface?>? list;
List<ObjB ?>? list2;
ObjA({this.name, this.list, this.list2});
}
I have a class that takes one of its subclasses as an argument. When constructing that subclass, I want to be able to use this as the value of that argument:
class A(val b: B)
class B extends A(this)
However, this fails to compile
this can be used only in a class, object, or template
[error] class B extends A(this)
[error] ^
Is there any way to get around this? I'm pretty sure that a pattern like this can be written in Java.
I'm not so sure about the last statement:
public class MyClass {
static class A {
A(B b) {
System.out.println(b.value);
}
}
static class B extends A {
String value;;
B() {
super(this);
value = "x";
}
}
public static void main(String args[]) {
new B();
}
}
gives the following error:
/MyClass.java:10: error: cannot reference this before supertype constructor has been called
super(this);
^
There is no good reason to attempt to let the this reference escape the scope of the constructor before the object itself has been constructed. Refactor it.
I'm having some trouble with deriving a pointer to a derived class. I think it has something to do with a constructor. Do I have to create a new constructor in my derived class? How to I create a pointer from a derived class? Thanks
Class Base
{
public:
int myfunction(int a,int b,int c)
{
return a+b+c;
}
};
Class Derived: public Base
{
int newfunction(int a, int b, int c)
{
return a*b*c;
};
};
int main()
{
// this doesn't work at all.. I get all errors every time I try to refer to the object
//instantiated from my derived class.
//I know it's my lack of understanding.
Derived *NewObject = new Derived;
//Why wont this work?
}
C++ is case sensitive, and the keyword class is lowercase. You wrote Class for both classes, and it looks like it's the only issue with your code.
I want to get access to an argument in a private constructor without using mutable variables:
class Class1 {
val strArgPublic = // get strArg argument from the private constructor. How?
private def this(strArg: String) = {
//.....
}
}
I want not only get strArg and return it, but change it a little bit and return a new modified copy of it.
How can I do this?
There is not only private constructor in your class. There is also a public constructor. You should decide what will be a value of strArgPublic after public constructor. If there is should be no public constructor you should define your class like this:
class Class1 private(strArg: String) {
val strArgPublic = transform(strArg)
}
If there should be a parameterless public constructor you could define one as auxiliary constructor:
class Class1 private(strArg: String) {
val strArgPublic = transform(strArg)
def this() = this("default")
}
I've seen (and heard) quite a bit of noise about adding virtual classes to Scala (it already has virtual types, according to Martin Odersky).
What is a layman's perspective (perhaps with an example) on what a virtual type is and what could be possible were Scala to have virtual classes?
([I have no experience with C or C++, so would prefer any answer not to refer to these languages].)
Virtual types are simple:
Classes and traits can have type members. E.g.
trait Foo {
type T
}
They can be refined (but not overridden once defined):
class Foo1 extends Foo {
type T <: AnyVal
}
class Foo2 extends Foo1 {
override type T = Boolean
}
class Foo3 extends Foo2 {
// override type T = Int // rejected by the compiler – would be unsound
}
Here is an example of virtual classes in a Java-descendent language (cclass is a virtual class):
Features of Virtual Classes
Let's look
to another example to study the
possibilities of virtual classes. We
will use virtual classes to extend a
collaboration with a totally new
funtionality. Let’s say we have a core
data model to represent expressions:
public cclass ExprModel {
abstract public cclass Expr {}
public cclass Constant extends Expr {
protected int _val;
public Constant(int val) {
_val = val;
}
}
abstract public cclass BinaryExpr {
protected Expr _left;
protected Expr _right;
public BinaryExpr(Expr left, Expr right) {
_left = left;
_right = right;
}
}
public cclass Add extends BinaryExpr {}
public cclass Mult extends BinaryExpr {}
}
The collaboration defines Expr as the
base class for all expressions,
concrete classes to represent
constants, addition and
multiplication. Class BinaryExpr
implements the common functionality of
all expressions with two operands.
Note that the current version of
Caesar does not support constructors
with parameters and abstract methods
in cclass. The code below demonstrates
how sample expressions can be built
using such collaboration:
public model.Expr buildSampleExpr(final ExprModel model) {
model.Expr const1 = model.new Constant(-3);
model.Expr const2 = model.new Constant(2);
model.Expr op1 = model.new Mult(const1, const2);
model.Expr const3 = model.new Constant(5);
model.Expr op2 = model.new Add(op1, const3);
return op2;
}
The collaboration defines Expr as the
base class for all expressions,
concrete classes to represent
constants, addition and
multiplication. Class BinaryExpr
implements the common functionality of
all expressions with two operands.
There are a lot of different
functionality related with
expressions: their evaluation,
formatting expressions to simple text
in infix or postfix order, various
consistency checks, lookups and
transformations. We want to keep all
this specific functionality separated
from each other and from the core data
model. This can be achieved with the
help of virtual classes. For example,
the collaboration below extends the
core model with simple expression
formatting functionality:
public cclass ExprFormat extends ExprModel {
abstract public cclass Expr {
abstract public void String format();
}
public cclass Constant {
public void String format() {
return _val < 0 ? “(“ + _val + “)” : “” + _val;
}
}
abstract public cclass BinaryExpr {
public void String format() {
return “(” + _left.format() + getOperSymbol()
+ _right.format() + “)”;
}
abstract public void String getOperSymbol();
}
public cclass Add {
public void String getOperSymbol() { return “+”; }
}
public cclass Mult {
public void String getOperSymbol() { return “*”; }
}
}
This short example demonstrates
various features of virtual classes:
There is no need to repeat inheritance relationships between
virtual classes if they are already
defined in the supercollaboration. For
example ExprModel defines Constant as
subclass of Expr. It means that
Constant is implicitly assumed as
subclass of Expr in ExprFormat as
well.
Virtual classes can use the fields and methods defined in their
older versions. For example
ExprFormat.BinaryExpr can use fields
_left and _right defined in ExprModel.BinaryExpr.
The functionality defined in the overridden virtual classes can be
accessed without type casts. For
example, fields _left and _right of
BinaryExpr were initially declared
with type Expr of ExprModel, which
does not have method format(), but in
the context of ExprFormat the new
version of Expr is assumed as the type
of _left and _right. So format() can
be called without any type casts.
The methods introduced in the overridden virtual classes can be
again overridden in the new versions
of subclasses. For example overridden
Expr introduces method format(), which
can be overridden in BinaryExpr. While
Add and Mult do not override this
method further, they inherit the
format() of BinaryExpr.
Besides the demonstrated properties,
the overridden virtual classes can
also
introduce new data fields,
implement new interfaces,
introduce new inheritance relationships.