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 8716945
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 13, 20262026-06-13T06:12:06+00:00 2026-06-13T06:12:06+00:00

I have an Accessor class that retrieves Items. It can also take an Item

  • 0

I have an Accessor class that retrieves Items. It can also take an Item as a parameter and return the latest version of that Item from the database. When it creates an Item it passes itself as a parameter to the Item.

I want the compiler to statically require that an Accessor instance will only accept Items that were created by itself. This was covered by How to use Scala's singleton-object types? however I also want an Item instance to be able to pass itself as a parameter to its own Accessor to retrieve the latest version of itself.

The difficulty with this is that a type parameter in the Item class definition like so

class Item[A <: Accessor](acc: A)

cannot refer to the type of acc itself. From the perspective of Item acc.type <: A <: Accessor so this in Item, which is an Item[A], is not an Item[acc.type]. Thus this doesn’t work:

class Item[A <: Accessor](acc: A) {
    acc.accept(this) // Type Mismatch: found Item[A], required Item[Item.this.acc.type]
}

class Accessor {
    def make() = new Item[this.type](this)
    def accept(item: Item[this.type]) = "accepted"
}

I then tried this:

object A1 extends Accessor[A1.type](A1) // illegal cyclic reference involving object A1

class Item[+A <: Accessor[A]](acc: A) {
    acc.accept(this)
    A1.accept(this) // Compile error (good)
}

class Accessor[+A <: Accessor[A]](me: => A) {
    def make = new Item[A](me)
    def accept(item: Item[A]) = "accepted"
}

where the problem is actually creating an instance of Accessor.

I tried a variation on the above which turned out to be a messier incarnation of the same fundamental dilemma:

object A1 extends Accessor {
    type A = A1.type
    def me = A1
}

class Item[+AA <: Accessor](acc: AA {type A = AA}) {
    acc.accept(this)
    A1.accept(this) // Compile error (good)
}

class Accessor {
    type A <: Accessor
    def me: A // can't do {type A = A} because its a cyclic error again
    def make = new Item[A](me) // Type Mismatch: found this.A, required this.A {type A = Accessor.this.A}
    def accept(item: Item[A]) = "accepted"
}

Finally I tried making the A type parameter contravariant so that Item[A] is a subtype of Item[acc.type] and will be accepted by acc.

val a1 = new Accessor
val a2 = new Accessor
val item1 = a1.make
val item2 = a2.make
val itemA = new Item[Accessor](a2)
val item12 = new Item[A1.type](a2) // compile error (good)

a1.accept(itemA) // no compile error (bad), but I can prevent creation of Item[Accessor]s
a1.accept(item2) // compile error (good)

class Item[-A <: Accessor](acc: A) {
    acc.accept(this)
    val acc2 = new Accessor
    acc2.accept(this) // compile error (good) 
    // here Item[Accessor] <: Item[A] <: Item[acc.type] 
    // and Item[Accessor] <: Item[acc2.type]
    // but Item[A] is not necessarily <: Item[acc2.type]
}

class Accessor {
    def make() = new Item[this.type](this)
    def accept(item: Item[this.type]) = "accepted"
}

This comes closest to working of anything I have tried. The only problem is it stuffs up my object hierarchy because I can’t do this:

class ImmutableAccessor extends Accessor

class ImmutableItem[-A <: ImmutableAccessor](acc: A) extends Item[A] // fails due to contravariance in A

If only there were some way to specify that a type parameter must be a singleton type. So for example you could say (I’m inventing notation here)

class Item[A:type <: Accessor](acc: A)

And A would then be the singleton type of acc and we’d be laughing.

  • 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-06-13T06:12:07+00:00Added an answer on June 13, 2026 at 6:12 am

    The secret sauce we need here is to exploit the <:< class found in Predef, using an implicit value. You are quite right that the “with Singleton” didn’t do everything we wanted.

    class Item[-A <: Accessor](acc: A)(implicit sing: A <:< Singleton) {
      acc.accept(this)
    }
    
    class Accessor {
      def make() = new Item[this.type](this)
      def accept(item: Item[this.type]) = "accepted"
    }
    
    class BetterItem[-B <: BetterAccessor](b: B)(implicit bsing: B <:< Singleton)
        extends Item[B](b)(bsing)
    }
    
    class BetterAccessor extends Accessor
    

    Now the inheritance works better. We can do stuff like the following

    val a1 = new Accessor
    val a2 = new Accessor
    val b3 = new BetterAccessor
    
    val i1 = a1.make
    val i3 = b3.make
    
    a1.accept(i1)     // GOOD
    //a2.accept(i1)   // compile time error
    //b3.accept(i1)   // compile time error
    //new Item[Accessor](a2)   // compile time error
    //a1.accept(i3)   // compile time error
    b3.accept(i3)     // GOOD
    

    And we get compile time errors exactly where we want.

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

Sidebar

Related Questions

I have a class that is stored on the 'server' and multiple clients can
I have a class variable that I would like to set from an initilizer
I have a class that implements INotifyPropertyChanged and also has its own concept of
I have a custom class that has quite a few accessor methods for customizing
I have a class Player that contains a list of Accessory objects. There are
I have an object now: class Items attr_accessor :item_id, :name, :description, :rating def initialize(options
If I have a property 'gId' in my Java class what should the accessor
A have a class hierarchy that looks somethign like this: class AbstractDataType { public:
I'd like to provide an accessor on a class that provides an NSInputStream for
So, I currently have a Board class that is composed of Piece s. Each

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.