Override object inner trait

[Etienne Couritas]

Hello,

I try to override an object in a trait 

trait BaseEnum[T] {

  implicit object writes extends Writes[Enum] {

        def writes(....

  }

}

object ActionType extends BaseEnum[ActionType] {

implicit object writes extends Writes[ActionType] { 

              def writes(...

        }

}

ActionType extends Enum

I go an "overriding object writes in trait BaseEnum" but my eclipse said all is ok.

I wonder why it's impossible to override a object in a trait?

And what alternative can I use.

Cheers

Etienne.

[ramn.se ‘¸]

I believe the 'object' is final. You would have to use a val instead.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Som Snytt]

I wonder if policy does this by default.

$ scala -Yoverride-objects
Welcome to Scala version 2.11.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_11).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :pa
// Entering paste mode (ctrl-D to finish)

trait A { object X }
trait B extends A { override object X }

// Exiting paste mode, now interpreting.

defined trait A
defined trait B

[Etienne Couritas]

Hello, and thanks for your answer

There is a real différences bettween the use of val or the use of object?

And if the overriding of object are unable by default it's maybe there is some thing bad beyound the use of -Yoveride-objects?

[Jason Zaugg]

On Thu, Sep 25, 2014 at 11:14 PM, Etienne Couritas <e.cou...@gmail.com> wrote:

Hello, and thanks for your answer

There is a real différences bettween the use of val or the use of object?

And if the overriding of object are unable by default it's maybe there is some thing bad beyound the use of -Yoveride-objects?

I don't recommend that flag, there are some nasty unresolved issues with that feature.

-jason

[ramn.se ‘¸]

the 'object' is final, as we saw, and also defines a type which val doesn't.

[Etienne Couritas]

Define a type which cannot be override or instanciate is realy usefull ?

I can't realise the adventage of the object over the var. (in this case)

Because my va can contain an object with functions

[Jason Zaugg]

On Fri, Sep 26, 2014 at 1:13 AM, Etienne Couritas <e.cou...@gmail.com> wrote:

Define a type which cannot be override or instanciate is realy usefull ?

I can't realise the adventage of the object over the var. (in this case)

Because my va can contain an object with functions

If you want maximum flexibility, you need to resort to some boilerplate:

trait A {
  trait InnerApi { def foo: Int }
  type Inner <: InnerApi
  def Inner: Inner
}

trait B extends A {
  trait InnerApiB extends InnerApi { def bar: Int }
  type Inner <: InnerApiB
}

final class C extends B {
  class Inner extends InnerApiB { def bar = 0; def foo = bar } 
  def Inner = new Inner
}

-jason

​

[Etienne Couritas]

Hello,

That really interesting, I don't know that was possible.

I don't know if it's always a good alternative because the dev which write the inheriting class must know there is a defined type.

I thinks will use this solution i'ts seems clean for me.

It's possible to have 

trait B extends A {
 trait InnerApiB extends super.Inner { def bar: Int }
 type Inner <: InnerApiB
}

To not have to reference explicitly the super trait?

?

Etienne

[Jon Pretty]

I hope I'm understanding the question correctly, but you can't refer to the `Inner` in the supertrait if there's another `Inner` shadowing it, unless you qualify it, and prefixing it with `super.` is the way to do that.

There may be a better way of achieving the same high-level goal, but it looks like you might want something like virtual classes. These have been implemented as a research project using macros, though I'm not sure how robust they are currently. Have a look at:

  https://github.com/xmanu/scala-virtual-classes-annotation-macros

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jon Pretty | @propensive