Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6618501
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 25, 20262026-05-25T20:50:32+00:00 2026-05-25T20:50:32+00:00

I have a trait, which takes a type parameter, and I want to say

  • 0

I have a trait, which takes a type parameter, and I want to say that the objects that implements this trait will also conform to this type parameter (using generics, for Java’s compatibility)

The following code:

trait HandleOwner[SELF <: HandleOwner[SELF]] {
self : SELF =>
    // ...
    def handle: Handle[SELF]
}

trait Common[SELF <: Common[SELF]]  extends HandleOwner[SELF] {
    // ...
}

Gives me the following error:

illegal inheritance;  self-type test.Common[SELF] does not conform to
test.HandleOwner[SELF]'s selftype SELF

If I change Common to:

trait Common[SELF <: Common[SELF]]  extends HandleOwner[SELF] {
self : SELF =>
    // ...
}

Then the error goes away.

Why is it that I have to repeat the same declaration in every non-concrete type. If I would have a base class, and say “extends Comparable”, I don’t have to repeat “extends Comparable” in every derived type, as long as the concrete classes implement the compareTo method. I think it should be the same thing here. I am just saying that a type extending HandleOwner will be also a SELF, and the compiler should just accept it, and take it into consideration while not requiring every non-concrete subtype to repeat the same thing again.

A am doing this to avoid having to use a class-cast, but I will be literally extending every class from this trait, and I don’t see that I should have to repeat this declarations hundreds or even thousands of times!

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-25T20:50:32+00:00Added an answer on May 25, 2026 at 8:50 pm

    Self type is more akin to generic constraint than to inheritance. With class C[A <: B], the constraint must be repeated all along in subclasses : class D[A <: B] extends C[A]. The constraint must be repeated until it is satisfied, that is until you have chosen an actual parameter type which indeed satisfies <: B. Same for the self type. Writing self: A => does not makes your type extend A. It ensures that it will ultimately have to be mixed in with A before it is actually instantiated.

    On the opposite, when you extend Comparable, you have made your class a Comparable, not put a constraint for later on. But the fact that you need to implement compareTo has still to be repeated all along with abstract until you actually implement it.

    Certainly the compiler could do without repeating <: B, self: A =>, and abstract, the info is available to it. This is language designer choice. At least, having to repeat self: A => is not different from the rules everywhere else.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Say I have a number of trait s that each add some behaviour to
Say I have a trait that has two lists. Sometimes I'm interested in the
Let's say I have this trait trait Ctx[C, V[_]] I am unable to construct
I would like to have a sealed trait which have a declared method that
Say I have a set of Strings that I want to be ordered by
Let's say I want to determine the probability that I will upvote a question
I have a case class which takes a list of functions: case class A(q:Double,
I have an application, which I have re-factored so that I believe it is
Let's assume I want to create a trait that I can mix in into
I have been looking for a design that solves the following problem. It will

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.