<p>What you are looking for are called "self types", and have been studied theoretically for ~20 years or so. </p>

<p>For example, see <em>Safe Type Checking in a Statically-Typed Object-Oriented Programming Language</em> by Kim B. Bruce, in the 1993 POPL (Principles of Programming Languages), pp. 285-298. Off the top of my head, John Mitchell and Kathleen Fisher have also worked on this, and they may also be described in Abadi and Cardelli's book <em>A Theory of Objects</em>. </p>

<p>Scala supports them, but I don't know if other mainstream OO languages do. </p>

CC BY-SA 3.0
2013-11-29T16:39:40.867Z
Are you sure that Scala has exactly the feature the question asks for and Kim Bruce's paper describes? The paper uses `MyType` as a bound type variable, and `final_class` is essentially that, even though the binder is implicit. I'm not sure, but I don't think Scala can do this.
Martin Berger
CC BY-SA 3.0
2013-11-29T21:10:46.073Z
I'm pretty sure, but since I don't program in Scala, I'm not completely sure. In *Overview of the Scala Programming Language*, Odersky shows how Scala supports family polymorphism, which I think generalizes self types.
Neel Krishnaswami
CC BY-SA 3.0
2013-11-29T21:36:56.820Z
Yes, you are right. The `self.type` expression corresponds to `MyType` in Bruce's TOOPL.
Funnily enough, I do give that paper to our masters students every year, but this
particular section had never registered. Thanks.
Martin Berger
CC BY-SA 3.0
2013-11-30T20:14:24.690Z
@NeelKrishnaswami, you may or may not have noticed that OCaml also has this feature. `class type abelian = object ('s) method inverse : 's method add : 's -> 's end`
gasche
CC BY-SA 3.0
2013-11-29T15:29:25.440Z
2013-11-29T21:41:03.600Z
2013-11-29T21:41:03.600Z
Neel Krishnaswami
<p>Perhaps you are looking for modules. For example, the following code uses OCaml's module system to define a signature for monoids and two implementations:</p>

<pre><code>module type Monoid = sig
  type t
  val identity : t
  val oper : t -&gt; t -&gt; t
end

module IntSum : Monoid = struct
  type t = int
  let identity = 0
  let oper x y = x + y
end

module IntProd : Monoid = struct
   type t = int
   let identity = 1
   let oper x y = x * y
end
</code></pre>

<p>Does this qualify as OO? Hmm... What does OO mean again?</p>

<p>To give this more of a cstheory vibe: modules are related to existential types (but not the same thing, see below). In turn, existential types are essentially (second-order) existential quantification under the propositions-as-types correspondence. See Mitchell and Plotkin's <a href="http://dl.acm.org/citation.cfm?id=45065" rel="nofollow">Abstract types have existential type</a> (paywall) as well as 
Cardelli and Wegner's <a href="http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf" rel="nofollow">On Understanding Types,
Data Abstraction, and Polymorphism</a>. See also this HaskellWiki entry on <a href="http://www.haskell.org/haskellwiki/Existential_type" rel="nofollow">existential types</a>.</p>

<p>There are some subtleties to this point, however. See e.g. MacQueen's <a href="http://www.cs.cmu.edu/~rwh/courses/modules/papers/macqueen86/paper.pdf" rel="nofollow">Using Dependent Types to Express Modular Structure</a>.</p>

CC BY-SA 3.0
2013-11-29T13:51:03.037Z
2013-11-29T14:49:09.423Z
2013-11-29T14:49:09.423Z
Andrew Cave
<p>In Scala you can use parametric polymorphism for this, e.g. like so:</p>

<pre><code>trait A [ T ] {
   def f ( t : T ) : T
   def g ( t : T ) : T = t }

class AImpl () extends A [ AImpl ] {
   def f ( t : AImpl ) : AImpl = t }
</code></pre>

<p>(Traits are a generalisation of Java interfaces). This can be resolved at compile-time, although I don't know how the Scala compiler and the JVM  implement this. Other languages with expressive polymorphism should enable similar constructs.</p>

<p><strong>Edit following Neel's remarks:</strong> here is a Scala implementation that, I think, does exactly what you want, but without a hack like type-parameterisation.</p>

<pre><code>trait A { self =&gt;
  def f ( t : self.type ) : self.type
  def g ( t : self.type ) : self.type = t }

class AImpl () extends A {
  def f ( t : this.type ) : this.type = t }
</code></pre>

<p>Scala's <code>self=&gt; ...</code> construct gives you access to the <code>this</code> pointer in classes 'up the inheritance/implementation hierarchy', and <code>.type</code> give you the corresponding type. </p>

CC BY-SA 3.0
2013-11-29T12:00:56.727Z
That's something similar to Java Generics or C++ Templates, no? The problem I see is that this solution doesn't enforce that T extends or implements A. In any case, I suppose it's possible :) . Thanks.
castarco
CC BY-SA 3.0
2013-11-29T12:06:01.613Z
Ok, i was wrong in one point. Event taking into account that i can enforce many restrictions on T... this solution has one problem yet: we cannot enforce the type T to be equal to AImpl in the trait definition... the contract can be broken.
castarco
CC BY-SA 3.0
2013-11-29T12:48:03.250Z
You can change the trait definition to `trait A [ T <: AImpl ] { ... }`. That forces the type parameter to be (a subclass of) `AImpl`.
Martin Berger
CC BY-SA 3.0
2013-11-29T13:02:07.853Z
But this solution makes the trait no reusable in other classes that are not subclasses of AImpl.

The point i'm claiming is that there is no elegant solution in any popular OO language, and this lack of an elegant solution has no obvious reasons: in terms of performance is better to do the check in compile time than in run time.
castarco
CC BY-SA 3.0
2013-11-29T16:43:13.273Z
One other reason could be that it makes type-inference harder.
Martin Berger
CC BY-SA 3.0
2013-11-29T20:57:52.653Z
Type inference in OO languages?
Andrej Bauer
CC BY-SA 3.0
2013-11-29T21:41:43.360Z
@AndrejBauer Scala has partial type-inference. The question if a pragmatically
viable full type inference algorithm for Scala exists is open to the
best of my knowledge. Have you got information to the contrary?
Self-types can probably also make type-checking harder.
Martin Berger
CC BY-SA 3.0
2013-11-30T09:27:38.903Z
Well, since one point of OO is nominal subtyping, it probably doesn't even make sense to have full type inference.
Andrej Bauer
CC BY-SA 3.0
2013-11-29T11:42:15.063Z
2013-11-29T21:48:34.413Z
2013-11-29T21:48:34.413Z
Martin Berger
<p>I know that this question it not entirely theoretical, but I think that's the place where is more probable that someone knows the answer.</p>

<p>The question is: is there any OO strong typed language where I could "delay" the definition of the method's arguments types?</p>

<p>I'll write an example. Imagine I want to model abelian additive groups, and I program the following interface:</p>

<pre><code>interface AbelianAdditiveGroup
{
    public method add(b final_class) : final_class;
    public method additiveInverse() : final_class;
}
</code></pre>

<p>Where <strong>final_class</strong> is a keyword to tell the compiler to use the implementation class, not the AbelianAdditiveGroup or any other intermediate abstract class.</p>

<p>That's an example of what I'm searching. I think that using fixed interfaces or classes as argument types in these methods is a bad approach in a lot of cases because this causes that we have to do multiple runtime type checks in our code.</p>

<p>If there is no language with this feature... is there any good reason for this?</p>

<p>Thanks in advance :) .</p>

CC BY-SA 3.0
2013-11-29T20:55:51.923Z
Am I allowed to say "don't use object-oriented programming"?
Andrej Bauer
<pl.programming-languages><language-design><object-oriented>
Is there a language with strong typed interfaces where types resolution are "delayed"?
castarco
# Is there a language with strong typed interfaces where types resolution are "delayed"?

(Asked by: username_0 on 2013-11-29)

I know that this question it not entirely theoretical, but I think that's the place where is more probable that someone knows the answer.
The question is: is there any OO strong typed language where I could "delay" the definition of the method's arguments types?
I'll write an example. Imagine I want to model abelian additive groups, and I program the following interface:
interface AbelianAdditiveGroup
{
    public method add(b final_class) : final_class;
    public method additiveInverse() : final_class;
}

Where final_class is a keyword to tell the compiler to use the implementation class, not the AbelianAdditiveGroup or any other intermediate abstract class.
That's an example of what I'm searching. I think that using fixed interfaces or classes as argument types in these methods is a bad approach in a lot of cases because this causes that we have to do multiple runtime type checks in our code.
If there is no language with this feature... is there any good reason for this?
Thanks in advance :) .

**Tags:** pl.programming-languages, language-design, object-oriented
> **Comments:**
> **username_1**: Am I allowed to say "don't use object-oriented programming"?  

---

## 3 answers

### Answer by username_2 on 2013-11-29. Score: 5 | Accepted answer

What you are looking for are called "self types", and have been studied theoretically for ~20 years or so.

For example, see *Safe Type Checking in a Statically-Typed Object-Oriented Programming Language* by Kim B. Bruce, in the 1993 POPL (Principles of Programming Languages), pp. 285-298. Off the top of my head, John Mitchell and Kathleen Fisher have also worked on this, and they may also be described in Abadi and Cardelli's book *A Theory of Objects*.

Scala supports them, but I don't know if other mainstream OO languages do.

> **Comments:**
> **username_3**: Are you sure that Scala has exactly the feature the question asks for and Kim Bruce's paper describes? The paper uses `MyType` as a bound type variable, and `final_class` is essentially that, even though the binder is implicit. I'm not sure, but I don't think Scala can do this.  
> **username_2**: I'm pretty sure, but since I don't program in Scala, I'm not completely sure. In *Overview of the Scala Programming Language*, Odersky shows how Scala supports family polymorphism, which I think generalizes self types.  
> **username_3**: Yes, you are right. The `self.type` expression corresponds to `MyType` in Bruce's TOOPL. Funnily enough, I do give that paper to our masters students every year, but this particular section had never registered. Thanks.  
> **username_4**: @NeelKrishnaswami, you may or may not have noticed that OCaml also has this feature. `class type abelian = object ('s) method inverse : 's method add : 's -> 's end`  

---

### Answer by username_5 on 2013-11-29. Score: 4

Perhaps you are looking for modules. For example, the following code uses OCaml's module system to define a signature for monoids and two implementations:
module type Monoid = sig
  type t
  val identity : t
  val oper : t -> t -> t
end

module IntSum : Monoid = struct
  type t = int
  let identity = 0
  let oper x y = x + y
end

module IntProd : Monoid = struct
   type t = int
   let identity = 1
   let oper x y = x * y
end

Does this qualify as OO? Hmm... What does OO mean again?
To give this more of a cstheory vibe: modules are related to existential types (but not the same thing, see below). In turn, existential types are essentially (second-order) existential quantification under the propositions-as-types correspondence. See Mitchell and Plotkin's Abstract types have existential type (paywall) as well as 
Cardelli and Wegner's On Understanding Types,
Data Abstraction, and Polymorphism. See also this HaskellWiki entry on existential types.
There are some subtleties to this point, however. See e.g. MacQueen's Using Dependent Types to Express Modular Structure.


---

### Answer by username_3 on 2013-11-29. Score: 2

In Scala you can use parametric polymorphism for this, e.g. like so:
trait A [ T ] {
   def f ( t : T ) : T
   def g ( t : T ) : T = t }

class AImpl () extends A [ AImpl ] {
   def f ( t : AImpl ) : AImpl = t }

(Traits are a generalisation of Java interfaces). This can be resolved at compile-time, although I don't know how the Scala compiler and the JVM  implement this. Other languages with expressive polymorphism should enable similar constructs.
Edit following Neel's remarks: here is a Scala implementation that, I think, does exactly what you want, but without a hack like type-parameterisation.
trait A { self =>
  def f ( t : self.type ) : self.type
  def g ( t : self.type ) : self.type = t }

class AImpl () extends A {
  def f ( t : this.type ) : this.type = t }

Scala's self=> ... construct gives you access to the this pointer in classes 'up the inheritance/implementation hierarchy', and .type give you the corresponding type.

> **Comments:**
> **username_0**: That's something similar to Java Generics or C++ Templates, no? The problem I see is that this solution doesn't enforce that T extends or implements A. In any case, I suppose it's possible :) . Thanks.  
> **username_0**: Ok, i was wrong in one point. Event taking into account that i can enforce many restrictions on T... this solution has one problem yet: we cannot enforce the type T to be equal to AImpl in the trait definition... the contract can be broken.  
> **username_3**: You can change the trait definition to `trait A [ T <: AImpl ] { ... }`. That forces the type parameter to be (a subclass of) `AImpl`.  
> **username_0**: But this solution makes the trait no reusable in other classes that are not subclasses of AImpl.  The point i'm claiming is that there is no elegant solution in any popular OO language, and this lack of an elegant solution has no obvious reasons: in terms of performance is better to do the check in compile time than in run time.  
> **username_3**: One other reason could be that it makes type-inference harder.  
> **username_1**: Type inference in OO languages?  
> **username_3**: @AndrejBauer Scala has partial type-inference. The question if a pragmatically viable full type inference algorithm for Scala exists is open to the best of my knowledge. Have you got information to the contrary? Self-types can probably also make type-checking harder.  
> **username_1**: Well, since one point of OO is nominal subtyping, it probably doesn't even make sense to have full type inference.  

---

