Lex Spoon | 11 Feb 16:34

Re: [ANN] Scala 2.7.0-RC1

Alex Boisvert wrote:
> I see no mention of type annotations in the language changelog.   Could 
> you elaborate?

(Followups to gmain.comp.lang.scala)

For several months, I worked on optional support in scalac for 
annotations on types.  The support was only turned on if you compiled 
with -Xplug-types.  Now, the option is gone and you always get the support.

This is a pretty good foundation, I think, for the pluggable type 
systems that Gilad Bracha describes.  The work is supported by the 
Hasler Foundation, so hopefully they think it is a pretty good 
foundation, too.  :)

There are two interesting parts to it compared to Java annotations.  One 
is that you can put arbitrary type-checked expressions in your 
annotations, not just constants.  So @dim(Length/Time) is perfectly 
valid.  Second, there is sophisticated support for propagating type 
annotations through the type inference.  Here is a typical example:

   object Foo {
     val x = 3
     val y: Int @GreaterThan(x) = 10
   }

   val z = Foo.y  // inferred type is Int @GreaterThan(Foo.x)

Notice how the @GreaterThan(x) had to be rewritten as 
@GreaterThan(Foo.x).  Let me tell you, that was a long saga to get 
(Continue reading)

Judson, Ross | 11 Feb 22:42
Favicon

RE: Re: [ANN] Scala 2.7.0-RC1

Do implicits work with the annotated types? This can yield some nice
benefits, like automatically doing a security check on a session object
if the callee declares a @SecurityChecked annotation on the parameter.
Having an extra "dimension" of type information will find many uses.

RJ 

Lex Spoon | 12 Feb 23:24

Re: [ANN] Scala 2.7.0-RC1

Judson, Ross wrote:
> Do implicits work with the annotated types? This can yield some nice
> benefits, like automatically doing a security check on a session object
> if the callee declares a @SecurityChecked annotation on the parameter.
> Having an extra "dimension" of type information will find many uses.
> 

That does sound useful, but it would mean that an annotation can change 
the behavior of the program even when no plugins are loaded.  I lean 
towards Bracha's view, and that of Java's annotations, in suspecting 
this kind of overloading would be too tricky for programmers to 
understand what is happening.  Thus, leaving aside reflection, the 
behavior of a program should not change if you remove annotations.

What you could do, now, is *track* whether security checks have 
happened, and generate compile time errors if the programmer claimed 
something is @SecurityChecked when this cannot be verified.

-Lex

David Pollak | 11 Feb 23:02
Gravatar

Re: Re: [ANN] Scala 2.7.0-RC1

Ooohhh... this sounds wicked cool.  I'd love to hear "yes it works" and 
then see an example.

Judson, Ross wrote:
> Do implicits work with the annotated types? This can yield some nice
> benefits, like automatically doing a security check on a session object
> if the callee declares a @SecurityChecked annotation on the parameter.
> Having an extra "dimension" of type information will find many uses.
>
> RJ 
>   

Viktor Klang | 11 Feb 23:44
Picon

Re: Re: [ANN] Scala 2.7.0-RC1



On Feb 11, 2008 11:02 PM, David Pollak <dpp <at> athena.com> wrote:
Ooohhh... this sounds wicked cool.  I'd love to hear "yes it works" and
then see an example.

+x!
 


Judson, Ross wrote:
> Do implicits work with the annotated types? This can yield some nice
> benefits, like automatically doing a security check on a session object
> if the callee declares a <at> SecurityChecked annotation on the parameter.
> Having an extra "dimension" of type information will find many uses.
>
> RJ
>




--
_____________________________________
/                                                                 \
       /lift/ committer (www.liftweb.net)
     SGS member (Scala Group Sweden)
 SEJUG member (Swedish Java User Group)
\_____________________________________/

Gmane