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

annotation imports

3 replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

[Sorry to keep the firehose on you: I have a lot of things coming
together and I'm trying to get the dependencies in place so the really
good stuff can happen.]

We've been sensibly putting (most) recent annotations in
scala.annotation but a lot of the early ones are in the scala package.
It's fairly annoying having to add an import anytime one wants to use
the more recent ones even though the use of an identifier in a @XXX
context means there is almost never going to be ambiguity.

PROPOSAL: default scope for @foo(...) includes scala.annotation._ in the
same way everything else includes java.lang/scala/Predef. This would
also let us move all the remaining ones into scala.annotation without
breaking anything.

(In a similar vein, I implemented the @conditional -Xinclude and
-Xexclude settings to look in the scala.annotation.conditional object,
so you can use fully qualified names or choose from whatever simple
named defaults we offer in there, which will surely cover most use
cases.)

Here's the list of annotations at the top:

SerialVersionUID.scala
cloneable.scala
deprecated.scala
deprecatedName.scala
inline.scala
native.scala
noinline.scala
remote.scala
serializable.scala
specialized.scala
throws.scala
transient.scala
volatile.scala

Here are the ones in or under scala.annotation:

./elidable.scala
./implicitNotFound.scala
./migration.scala
./strictfp.scala
./switch.scala
./tailrec.scala
./target/beanGetter.scala
./target/beanSetter.scala
./target/field.scala
./target/getter.scala
./target/param.scala
./target/setter.scala
./unchecked/uncheckedStable.scala
./unchecked/uncheckedVariance.scala

--
Paul Phillips | A Sunday school is a prison in which children do
Vivid | penance for the evil conscience of their parents.
Empiricist | -- H. L. Mencken
pp: i haul pills |----------* http://www.improving.org/paulp/ *----------

Martin Odersky
Joined: 2009-10-07,
User offline. Last seen 42 years 45 weeks ago.
Re: annotation imports

I see the interest but I am not too keen implementing it. It would be
a pesky special case both for the compiler and the spec. The problem
is that you need to slip in a scope somewhere deep in a set of scopes
when looking at an annotation. That's not something that's done
essewhere, so it would be a new and messy concept for namespace
management.

That said, I also think we should move annotations systematically to
the annotation package and keep for the moment type aliases in scala.
We can decide later whether we want to deprecate some of these aluases.

Martin

Sent from my phone

On Nov 5, 2010, at 19:13, Paul Phillips wrote:

> [Sorry to keep the firehose on you: I have a lot of things coming
> together and I'm trying to get the dependencies in place so the really
> good stuff can happen.]
>
> We've been sensibly putting (most) recent annotations in
> scala.annotation but a lot of the early ones are in the scala package.
> It's fairly annoying having to add an import anytime one wants to use
> the more recent ones even though the use of an identifier in a @XXX
> context means there is almost never going to be ambiguity.
>
> PROPOSAL: default scope for @foo(...) includes scala.annotation._ in
> the
> same way everything else includes java.lang/scala/Predef. This would
> also let us move all the remaining ones into scala.annotation without
> breaking anything.
>
> (In a similar vein, I implemented the @conditional -Xinclude and
> -Xexclude settings to look in the scala.annotation.conditional object,
> so you can use fully qualified names or choose from whatever simple
> named defaults we offer in there, which will surely cover most use
> cases.)
>
> Here's the list of annotations at the top:
>
> SerialVersionUID.scala
> cloneable.scala
> deprecated.scala
> deprecatedName.scala
> inline.scala
> native.scala
> noinline.scala
> remote.scala
> serializable.scala
> specialized.scala
> throws.scala
> transient.scala
> volatile.scala
>
> Here are the ones in or under scala.annotation:
>
> ./elidable.scala
> ./implicitNotFound.scala
> ./migration.scala
> ./strictfp.scala
> ./switch.scala
> ./tailrec.scala
> ./target/beanGetter.scala
> ./target/beanSetter.scala
> ./target/field.scala
> ./target/getter.scala
> ./target/param.scala
> ./target/setter.scala
> ./unchecked/uncheckedStable.scala
> ./unchecked/uncheckedVariance.scala
>
> --
> Paul Phillips | A Sunday school is a prison in which children do
> Vivid | penance for the evil conscience of their parents.
> Empiricist | -- H. L. Mencken
> pp: i haul pills |----------* http://www.improving.org/paulp/
> *----------

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: annotation imports

On Fri, Nov 05, 2010 at 07:44:58PM +0100, Martin Odersky wrote:
> That said, I also think we should move annotations systematically to
> the annotation package and keep for the moment type aliases in scala.
> We can decide later whether we want to deprecate some of these
> aluases.

That sounds good, and satisfies the orderliness compulsion for today.

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: annotation imports
Off topic, but what does uncheckedStable do and why doesn't it solve the problem of pattern matching on classOf?

On Fri, Nov 5, 2010 at 3:04 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Fri, Nov 05, 2010 at 07:44:58PM +0100, Martin Odersky wrote:
> That said, I also think we should move annotations systematically to
> the annotation package and keep for the moment type aliases in scala.
> We can decide later whether we want to deprecate some of these
> aluases.

That sounds good, and satisfies the orderliness compulsion for today.

--
Paul Phillips      | Atheists dig the best foxholes.
Analgesic          |
Empiricist         |
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

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