Can someone detail the minus side of annotations? (Other than "it's just not
the Scala/Lift way." :) Preferably in terms of what goal it inhibits.)
Also keep in mind that the "exception" in terms of the code being in a Java
source file is a temporary workaround that will be replaced when it's possible,
so it's not a huge exception.
-------------------------------------
David Pollak<feeder.of.the.be...@gmail.com> wrote:
On Sun, Sep 13, 2009 at 3: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)
>
Is this even possible? I think that it might be a problem to extend String,
which is a final class.
>
> 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.
>
Yes, this is absolutely correct.
The issue then gets to "when do you have an exception to a rule?"
I'm not sure this is the exception, but it's the closest thing I've seen.
Perhaps an alternative could be a companion object:
object Foo {
val jsonFieldMapping: List[(String, String)] = ...
}
This is consistent with companion objects and implicits.
On the other hand, I lean (just a little) toward annotations in this case...
it's one of the few times I've seen annotations used in what I consider to
be a sane way.
I'm interested in hearing Marius' (and others') further thoughts as to
whether this should be the exception "that proves the rule."
Thanks,
David
> 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
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
