On Mon, Sep 14, 2009 at 9:00 PM, Naftoli Gugenheim wrote:
>
> 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!
>
> ---
Wow, isn't it amazing how passionate people could be about something without
having a reason? ;)
Thanks for your answers, DPP!
-
Indrajit Raychaudhuri wrote:
Absolutely, and just limit to that, no more.
/Indrajit
On Sep 14, 11:22 pm, Viktor Klang wrote:
>
On Mon, Sep 14, 2009 at 8:52 PM, Timothy Perrett wrote:
> 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 if your
> inter-opi
Absolutely, and just limit to that, no more.
/Indrajit
On Sep 14, 11:22 pm, Viktor Klang 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 8:06 PM, Timothy P
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 me
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 wrote:
>
> Whilst I cant speak for anyone else - looking at Java these days
> generally makes me want
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
On Mon, Sep 14, 2009 at 10:34 AM, Naftoli Gugenheim wrote:
>
> 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 single
language
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 p
On Mon, Sep 14, 2009 at 4:26 AM, Joni Freeman wrote:
>
> On Sep 14, 8:14 am, Naftoli Gugenheim 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 suppo
On Sun, Sep 13, 2009 at 10:02 PM, Naftoli Gugenheim wrote:
>
> 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 order we'll start wit
On Sun, Sep 13, 2009 at 3:31 PM, marius d. wrote:
>
>
>
> On Sep 13, 3:15 pm, Joni Freeman 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.
On Sep 14, 8:14 am, Naftoli Gugenheim 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 is no longer nec
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
c
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 Freeman wrote:
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
Is there a list of rules for committers to stick to? Especially considering the
review board system being put into place.
-
Joni Freeman wrote:
Extending ClassfileAnnotation does not work at the moment. Excerpt
from "Programming Scala" (http://programming-sc
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
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 fut
On Sep 13, 3:15 pm, Joni Freeman 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
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 fi
21 matches
Mail list logo
