As far as I understand it, classes –as they are supported in OOP languages such as C++, Java, and Scala – define the type of each object I can instantiate with that class.

Not all features of a class are relevant to the type of its instances: Private methods, the constructor, the destructor (in C++), and the methods' implementations.

My question: Are the static methods of a class part of the instances' type?

Related: Is there a distinct type of a class (calling new to get an instance, calling its static methods) and the type of the class' instances (calling the public methods).

I'm happy for all suggestions and corrections of any invalid assumptions I have made.

  • not sure what you mean, they are part of the type, but they don't have access to the instance
    – Ewan
    May 16, 2015 at 12:44
  • 3
    Scala doesn't have static methods, Java doesn't have destructors, C++ doesn't have finalizers, are you sure you want to lump all of those together? Scala, in particular, not only doesn't have static methods, it has no statics at all. Plus, there are lots things in Scala which are types but aren't classes. Heck, there are lots of things in Java which are types but aren't classes. May 16, 2015 at 13:00
  • @JörgWMittag: All those languages have the concept of a class, that's why I listed them to make sure we're talking about the same construct. Scala's companion objects and their methods are the equivalent of static methods. May 16, 2015 at 13:04
  • 1
    @MatthiasBraun I think Jorg's point is that it's possible the answer is different for each language. My expertise is with C++, so my answer is specific to that language (which I didn't fully realize when I first wrote it); I have no idea if it's also valid for Java or Scala.
    – Ixrec
    May 16, 2015 at 14:18
  • @MatthiasBraun your example of "... relevant to the type ..." seems to refer to visibility instead.
    – rwong
    May 16, 2015 at 14:52

2 Answers 2


Any field/method that a user of the class can access is part of the type, because all code using that type has to know it exists, whether it's static, how many arguments it takes and so on in order for code using it to compile properly. For instance, you'd have no way of knowing if Foo::field was valid code unless static int field (or something similar) was part of Foo's class definition. So the short answer to your question is yes, static methods are part of the type (at least in C++).

It sounds like your confusion stems from the fact that a static field/method is not contained within or carried around by every individual instance of a class. Of course, the code implementing the class' methods is also not carried around by every individual instance of a class, so this property is not unique to statics.

In general, a class can and usually does tell you a lot more about its objects/instances than just the data each instance contains. That's a big part of what makes OOP so powerful.

I'm not sure I understand your related question, but I believe the answer is: The class is the type of the instances. The type of a class would be a type of a type, which is the sort of thing we don't normally talk about in C++ since it has no real meaning in the language (with the very debatable exception of derived/base classes).


Not all features of a class are relevant to the type of its instances: Private methods, the constructor, the destructor (in C++), and the methods' implementations.

This is not usually true. In a nominative type system, nothing about the type matters but the name (and where it exists in the hierarchy if you have subtyping). As the compiler goes through your code, it matches the type name to the type name of parameters to make sure the code is well formed. The type checker does not care what functions are on the type. The type checker does not care what fields are on the type.

Earlier parts of the compiler, where it uses the symbol table to resolve identifiers does. In semantic analysis, where the compiler makes sure you're doing function invocation on a function rather than an int does. But those parts don't deal with types beyond "is A equal to, or a subtype of B?".

Structural type systems on the other hand do care about the guts of a class. Since their definition of subtyping is "is A's fields/functions compatible with the fields/functions of B?", fields and functions are part of the type definition. But here, statics don't count since they're not part of the instance type. I guess that a language could have a type for the singleton instance of the statics, but I know of none that actually do.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.