-4

Does Smalltalk support covariance and contravariance? Do these concepts apply to this language?

Leandro Caniglia
  • 14,495
  • 4
  • 29
  • 51
user3006595
  • 31
  • 5

2 Answers2

5

Covariance and contravariance are concepts that relate to declared types of arguments and return values. For example, method arguments are contravariant if the types of the arguments in subclass methods can specify a more general type than the types in the superclass.

Smalltalk has no static type declarations. You can apply the concepts of covariance and contravariance but since the language allows you to send any message to any object, it won't enforce any rules that covariance and contravariance may entail.

So, yes, Smalltalk supports covariance and contravariance in the sense that it allows you to use those concepts and no in the sense that it just doesn't care one way or the other.

David Buck
  • 2,847
  • 15
  • 16
0

Smalltalk is strictly and dynamically typed. It only cares if a parameter object responds to the messages it gets send. If not, it raises a DNU (Does Not Understand) at run time when the message is sent (which you can handle either by hand, or respond to in code). At compile time, every parameter is an object, and you are allowed to send any message to any object.

Stephan Eggermont
  • 15,847
  • 1
  • 38
  • 65
  • Could you elaborate a little bit more about Smalltalk being "strictly typed"? – Leandro Caniglia Jul 11 '15 at 08:49
  • 1
    I'd rather not. The number of different definitions of this make it perhaps not the right one to use. – Stephan Eggermont Jul 11 '15 at 11:00
  • Strictly (also "strong") means that the user of a variable cannot change the interpretation (by purpose or accident), as in other languages. Those other languages are typically statically typed, where the compiler then compensates for this and ensures proper access (with controlled - as in "java" or uncontrolled "casts" (as in C/C++), if that is required, or if the static type system is not sufficient). In Smalltalk, the object itself "knows" of what type it is, and this cannot be "reinterpreted" by a user of the object who has a reference on it (neither willingly, not by accident). – blabla999 Oct 29 '15 at 22:45