This page is no longer maintained — Please continue to the home page at www.scala-lang.org

final traits

6 replies
Justin Johansson
Joined: 2008-12-14,
User offline. Last seen 3 years 45 weeks ago.

Hi all,

Experimenting with the final keyword on trait one soon discovers that having

**

final trait MyTrait {
}

gives rise to a trait that is completely orphaned in that it cannot be used
either as

1.

trait MyTraitEx extends MyTrait {
}

or as

2.

class MyClass extends AnyRef with MyTrait {
}

due to "illegal inheritance from final trait MyTrait" in both use cases.

Given that traits cannot be instantiated directly,
would it make sense to change the semantics of "final trait" so that use
case 1. above
is continued to be disallowed but use case 2. is allowed?

In other words, a final trait would mean a trait that cannot be extended
"traitwise" but can
nevertheless be used to extend an existing class via "with'.

Without such a change in semantics, it seems reasonable that the final
keyword should
not be allowed to qualify a trait and ** should therefore be disallowed.

What do others think?

Regards
Justin Johansson

ewilligers
Joined: 2008-08-20,
User offline. Last seen 3 years 17 weeks ago.
Re: final traits

Justin Johansson wrote:

> it seems reasonable that the final
> keyword should
> not be allowed to qualify a trait and ** should therefore be disallowed.

IMHO traits and abstract classes should not be able to be final.

BTW, why are abstract types allowed in non-abstract classes?
class C {
type T
}
val c = new C

Also, there's no particular need to allow "abstract trait" or "final
object" - both can be reported as redundant. Or should this be left to
static style checkers?

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: final traits

On Thu, Dec 18, 2008 at 12:22 AM, Eric Willigers <ewilligers [at] gmail [dot] com> wrote:
> Justin Johansson wrote:
>
>> it seems reasonable that the final
>> keyword should
>> not be allowed to qualify a trait and ** should therefore be disallowed.
>
> IMHO traits and abstract classes should not be able to be final.
>
>
> BTW, why are abstract types allowed in non-abstract classes?
> class C {
> type T
> }
> val c = new C
>
Why should that be not allowed? (In the generated code, T is
translated to its upper bound, as usual).

Cheers

ewilligers
Joined: 2008-08-20,
User offline. Last seen 3 years 17 weeks ago.
Re: final traits

martin odersky wrote:
>> BTW, why are abstract types allowed in non-abstract classes?
>> class C {
>> type T
>> }
>> val c = new C
>>
> Why should that be not allowed? (In the generated code, T is
> translated to its upper bound, as usual).

ok, no problem then, I thought it left T unspecified.

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: final traits

On Thu, Dec 18, 2008 at 12:38 AM, Eric Willigers <ewilligers [at] gmail [dot] com> wrote:
> martin odersky wrote:
>>>
>>> BTW, why are abstract types allowed in non-abstract classes?
>>> class C {
>>> type T
>>> }
>>> val c = new C
>>>
>> Why should that be not allowed? (In the generated code, T is
>> translated to its upper bound, as usual).
>
> ok, no problem then, I thought it left T unspecified.
>
Just to be clear: T _is_ unspecified as a type for the type system.
That's why the translation can pick any type it likes, because the
type checker will prevent you from relying that it is that type (I
hope I make sense here...)

Cheers

Landei
Joined: 2008-12-18,
User offline. Last seen 45 weeks 4 days ago.
Re: final traits

Justin Johansson wrote:
>
> ...
> Without such a change in semantics, it seems reasonable that the final
> keyword should not be allowed to qualify a trait and ** should therefore
> be disallowed.
>
> What do others think?
>
> Regards
> Justin Johansson
>

Who says that you need to be able to instantiate a trait? They can be used
in Phantom Types (e.g. look at the typesafe builder pattern), where it makes
sense to prevent instantiation.

Just my 10 binary cents...

Take care!
Daniel

Florian Hars
Joined: 2008-12-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: final traits

Eric Willigers schrieb:
> Also, there's no particular need to allow "abstract trait" or "final
> object"

"final object" might be useful if the extension to make objects inheritable
that Martin hinted at in the "Object types problem" thread a few days ago
ever gets impelmented...

- Florian

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland