Extending ClassfileAnnotation does not work at the moment. Excerpt
from "Programming Scala" (http://programming-scala.labs.oreilly.com/
ch13.html"):
"Another child of scala.Annotation that is intended to be a parent of
other annotations is the trait scala.ClassfileAnnotation. It is
supposed to be used for annotations that should have runtime
retention, i.e., the annotations should be visible in the class file
so they are available at runtime. However, actually using it with the
JDK version of Scala results in compiler errors...". "Hence, if you
want runtime visibility, you have to implement the annotation in
Java."
Cheers Joni
On Sep 14, 4:18 am, Josh Suereth <joshua.suer...@gmail.com> wrote:
> Scala does support annotations, they're just anemic at this point.
>
> I hadn't tried, but does extending ClassfileAnnotation allow runtime
> visibility? That would give you a pure scala implementation. If not, I
> think we need to rally for StaticAnnotation/ClassfileAnnotation to be joined
> by their future brother RuntimeAnnotation.
>
> - Josh
>
> On Sun, Sep 13, 2009 at 6:31 PM, marius d. <marius.dan...@gmail.com> wrote:
>
> > On Sep 13, 3:15 pm, Joni Freeman <freeman.j...@gmail.com> wrote:
> > > Hi,
>
> > > That annotation is used to configure the json path when extracting
> > > values. By default the extraction code assumes that case class
> > > parameter names match with json field names. For instance these match:
>
> > > case class Foo(bar: String, baz: Int)
> > > { "bar": "qwerty", "baz": 10 }
>
> > > But sometimes json field names can contain characters which are not
> > > allowed in Scala identifiers. For example:
> > > { "foo-bar": "qwerty", "baz": 10 }
>
> > > Now, to able to extract this we have to somehow tell the extractor the
> > > exact path explicitly. Currently @path annotation is used for that:
> > > case class Foo(@path("foo-bar") bar: String, baz: Int)
>
> > > I don't see how a trait can accomplish this, maybe I'm missing
> > > something?
>
> > > The reason why it is in Java is that Scala annotations are not
> > > accessible at runtime.
>
> > Right but I'd also suggest removing Java code from Lift stack. The
> > above can be easily achieved by introducing a trait such as:
>
> > case class Foo(bar: String with Nominator, baz: Int)
>
> > Lift is a 100% Scala code with zero Java code. We also have strong
> > opinions in the team that we should stay away from annotations.
>
> > one option would be something like this:
>
> > Lift would have :
>
> > trait Nominator{
> > def name : String
> > }
>
> > In user's code:
>
> > case class Foo(bar: String with MyNominator, baz: Int)
>
> > trait MyNominator extends Nominator {
> > def name = "foo-bar"
> > }
>
> > Yes it is more verbose then the annotation but IMHO it is more Scala-
> > ish & Lift-ish.
>
> > > Cheers Joni
>
> > > On Sep 13, 11:03 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
>
> > > > Just had a browse over the latest commit and found the following in
> > > > path.java:
>
> > > > @Retention(RetentionPolicy.RUNTIME)
> > > > @Target(ElementType.TYPE)
> > > > public @interface path {
> > > > public String value();
>
> > > > }
>
> > > > Any reason were not using a trait etc to complete the same
> > > > functionality?
>
> > > > Cheers, Tim
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
