On Sep 14, 8:14 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Can't you require back ticks and name the case class members the same as in
the JSON?
This works pretty well, thanks for pointing out this solution! I added
name demangling to support back ticks and removed @path annotation.
It
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
On Sun, Sep 13, 2009 at 10:02 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Is there a list of rules for committers to stick to? Especially considering
the review board system being put into place.
No... it's been word of mouth to date. Maybe after we get user-level
documentation in
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
On Mon, Sep 14, 2009 at 10:34 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
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.)
Annotations inhibit the goal of simple, uniform code written in a
Whilst I cant speak for anyone else - looking at Java these days
generally makes me want to be sick and annotations are simply
convulsion inducing ;-)
There are some issues from a technical perspective with Scala
annotations (like deep nested annotations for JPA), but otherwise, in
terms of lift
For me, annotations in Scala are permissible when having to deal with Java
frameworks that need annotations to work.
(examples: JAX-RS, JPA et al)
On Mon, Sep 14, 2009 at 8:06 PM, Timothy Perrett timo...@getintheloop.euwrote:
Whilst I cant speak for anyone else - looking at Java these days
Viktor you disappoint me! Was hoping you might chime in with some
witty retort about java ;-) lol.
Your right though - sometimes there is just no other way if your inter-
oping with some java framework that loves annotations.
Cheers, Tim
On 14 Sep 2009, at 19:22, Viktor Klang wrote:
For
Absolutely, and just limit to that, no more.
/Indrajit
On Sep 14, 11:22 pm, Viktor Klang viktor.kl...@gmail.com wrote:
For me, annotations in Scala are permissible when having to deal with Java
frameworks that need annotations to work.
(examples: JAX-RS, JPA et al)
On Mon, Sep 14, 2009 at
On Mon, Sep 14, 2009 at 8:52 PM, Timothy Perrett timo...@getintheloop.euwrote:
Viktor you disappoint me! Was hoping you might chime in with some witty
retort about java ;-) lol.
Sorry mate, I'll have to buy you a beer at Devoxx! :D
Your right though - sometimes there is just no other way
Wow, isn't it amazing how passionate people could be about something without
having a reason? ;)
Thanks for your answers, DPP!
-
Indrajit Raychaudhuriindraj...@gmail.com wrote:
Absolutely, and just limit to that, no more.
/Indrajit
On Sep 14, 11:22 pm,
On Mon, Sep 14, 2009 at 9:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Wow, isn't it amazing how passionate people could be about something
without having a reason? ;)
If you start me up if you start me up I'll never stop...
Thanks for your answers, DPP!
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
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:
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
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
Is there a list of rules for committers to stick to? Especially considering the
review board system being put into place.
-
Joni Freemanfreeman.j...@gmail.com wrote:
Extending ClassfileAnnotation does not work at the moment. Excerpt
from Programming Scala
Hi,
Here's another example.
{lotto:
{
id: 5,
winning-numbers: [2,45,34,23,7,5,3],
draw-date: 2009-09-14T18:00:00Z,
winners: [
{winner-id: 23, numbers: [2,45,34,23,3,5] },
{winner-id: 54, numbers:[52,3,12,11,18,22] }
]
}
}
At the moment I'm extracting this
Can't you require back ticks and name the case class members the same as in the
JSON?
Also if it comes to traits you may as well just allow an adapter that can read
and write values -- maybe a map of String to setter/getter functions.
-
Joni
Using back ticks could work, I'll have to check that out. Another
approach is to use map function, it works but there's a small
performance and verbosity hit.
import net.liftweb.json.JsonParser.parse
import net.liftweb.json.JsonAST.JField
implicit val formats = net.liftweb.json.DefaultFormats
20 matches
Mail list logo
