Asked  7 Months ago    Answers:  5   Viewed   54 times

Wondering what the difference is between the following:

Case 1: Base Class

public void DoIt();

Case 1: Inherited class

public new void DoIt();

Case 2: Base Class

public virtual void DoIt();

Case 2: Inherited class

public override void DoIt();

Both case 1 and 2 appear to have the same effect based on the tests I have run. Is there a difference, or a preferred way?



The override modifier may be used on virtual methods and must be used on abstract methods. This indicates for the compiler to use the last defined implementation of a method. Even if the method is called on a reference to the base class it will use the implementation overriding it.

public class Base
    public virtual void DoIt()

public class Derived : Base
    public override void DoIt()

Base b = new Derived();
b.DoIt();                      // Calls Derived.DoIt

will call Derived.DoIt if that overrides Base.DoIt.

The new modifier instructs the compiler to use your child class implementation instead of the parent class implementation. Any code that is not referencing your class but the parent class will use the parent class implementation.

public class Base
    public virtual void DoIt()

public class Derived : Base
    public new void DoIt()

Base b = new Derived();
Derived d = new Derived();

b.DoIt();                      // Calls Base.DoIt
d.DoIt();                      // Calls Derived.DoIt

Will first call Base.DoIt, then Derived.DoIt. They're effectively two entirely separate methods which happen to have the same name, rather than the derived method overriding the base method.

Source: Microsoft blog

Tuesday, June 1, 2021
answered 7 Months ago
>>> class C(str):
...     def __new__(cls, *args, **kw):
...         return str.__new__(cls, *args, **kw)
>>> c = C("hello world")
>>> type(c)
<class '__main__.C'>

>>> c.__class__.__mro__
(<class '__main__.C'>, <type 'str'>, <type 'basestring'>, <type 'object'>)

Since __init__ is called after the object is constructed, it is too late to modify the value for immutable types. Note that __new__ is a classmethod, so I have called the first parameter cls

See here for more information

>>> class C(str):
...     def __new__(cls, value, meta):
...         obj = str.__new__(cls, value)
...         obj.meta = meta
...         return obj
>>> c = C("hello world", "meta")
>>> c
'hello world'
>>> c.meta
Wednesday, June 2, 2021
answered 7 Months ago

Great question!

There are several key differences.


  • A newtype guarantees that your data will have exactly the same representation at runtime, as the type that you wrap.
  • While data declares a brand new data structure at runtime.

So the key point here is that the construct for the newtype is guaranteed to be erased at compile time.


  • data Book = Book Int Int


  • newtype Book = Book (Int, Int)


Note how it has exactly the same representation as a (Int,Int), since the Book constructor is erased.

  • data Book = Book (Int, Int)

data tuple

Has an additional Book constructor not present in the newtype.

  • data Book = Book {-# UNPACK #-}!Int {-# UNPACK #-}!Int

enter image description here

No pointers! The two Int fields are unboxed word-sized fields in the Book constructor.

Algebraic data types

Because of this need to erase the constructor, a newtype only works when wrapping a data type with a single constructor. There's no notion of "algebraic" newtypes. That is, you can't write a newtype equivalent of, say,

data Maybe a = Nothing
             | Just a

since it has more than one constructor. Nor can you write

newtype Book = Book Int Int


The fact that the constructor is erased leads to some very subtle differences in strictness between data and newtype. In particular, data introduces a type that is "lifted", meaning, essentially, that it has an additional way to evaluate to a bottom value. Since there's no additional constructor at runtime with newtype, this property doesn't hold.

That extra pointer in the Book to (,) constructor allows us to put a bottom value in.

As a result, newtype and data have slightly different strictness properties, as explained in the Haskell wiki article.


It doesn't make sense to unbox the components of a newtype, since there's no constructor. While it is perfectly reasonable to write:

data T = T {-# UNPACK #-}!Int

yielding a runtime object with a T constructor, and an Int# component. You just get a bare Int with newtype.


  • "Newtype" on the Haskell wiki
  • Norman Ramsey's answer about the strictness properties
Wednesday, June 9, 2021
answered 6 Months ago

All the support libraries are dropping the v4 v7 v12 v13 etc tags and everything is refactored into the androidx packages.

They are essentially the same but for future reference androidx will be the library that we should use in our apps.

Android studio 3.2 canary that comes out this week (week of May 14, 2018) should have the tool that allows automatic refactoring to the androidx packages. There was an announcement about this at google i/o 2018.

Sunday, July 18, 2021
answered 5 Months ago

This isn't really a good way to structure things. Do one of the following

1) Just don't change the return type, and override it normally in the subclass. In DerivedHandler you can return an instance of DerivedRequest using the base class signature of Request. Any client code using this can choose to cast it to DerivedRequest if they want to.

2) Use generics instead if they are not supposed to be polymorphic.

public abstract class HandlerBase<T> where T: Request
    public abstract T Request {get;set;}

public class Handler: HandlerBase<Request>()

public class DerivedHandler: HandlerBase<DerivedRequest>()
Friday, September 17, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :