martin odersky | 8 Dec 2008 00:03
Picon
Picon
Favicon

Re: Removing necessity to "overide" type aliases?



On Wed, Dec 3, 2008 at 3:42 AM, Lex Spoon <lex-2XCpF38ZseRg9hUCZPvPmw@public.gmane.org> wrote:

On Dec 2, 2008, at 4:17 PM, Geoffrey Alan Washburn wrote:
Lex Spoon wrote:

On Dec 2, 2008, at 10:30 AM, Geoffrey Alan Washburn wrote:
type Id[X] = X
trait A { type T = Int }
trait B extends A { override type T = Id[Int] }

that the user need not write "override"?  Assuming everything else
in the language works as expected, you can never change T to be
something else so really writing "override" is redundant.  Of
course, I would like this for the entirely selfish reason that I do
not have to explain this minor semantic difference between Scala
Classic and Scala proper.

I'm amazed that the above works at all!  Is B still considered a
subtype of A?  Or is A restricted from taking advantage of T being Int ?

Neither  Id[Int] is by definition Int, therefore it is perfectly sound.

Oh, Id is the identity type constructor!  I missed that, and thought it was a random parameterized type.



I guess my claim is that you cannot "accidentally" override a type definition.  For reasons of type soundness, you can only override a type definition with a type that is equivalent to the one originally defined.  So all that happens when a user "accidentally" overrides a type definition is that they just redefine exactly the same type they had before.  If you can't ever change the type, claiming you are overriding it is kind of vacuous.

I see.  Yes, that does make it seem silly to have to write "override".

yes, but is all this worth an extra rule in the spec?  I mean, who would write such a thing?

Cheers

 -- Martin


Gmane