[Lift] Re: Why isn't this a trait in lift-json?
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 is no longer necessary since there is two workarounds (back ticks and map function). The relevant commit which needs to be reviewed: http://github.com/jonifreeman/liftweb/commit/b452c56f2d4d4b3e289cffdf389b862cfad4da98 Other pending commits which are not pushed to dpp's master yet and needs to be reviewed: http://github.com/jonifreeman/liftweb/commit/4dd150c089d834912b1025e350161aa23beb9fb9 http://github.com/jonifreeman/liftweb/commit/a6ce11916e0c08eb00769cbd7a358bf508c5f064 http://github.com/jonifreeman/liftweb/commit/18a667371271cb5a7a9fd1e6d26ec3d06010937d http://github.com/jonifreeman/liftweb/commit/cee2a1f41503f3e6865d1fd091b4c6aefee82b41 Cheers Joni --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 order we'll start with committer rules.
-
Joni Freemanfreeman.j...@gmail.com wrote:
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
--
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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 Pollakfeeder.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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 single
language (the more languages, the more bugs and maintenance issues).
- Annotations are a separate language within a language. This means:
- There is no IDE support unless the IDE tries to support the
particular annotation
- Refactoring tools may or may not work with a given annotation
- It's something else for the developer to learn (the semantics of a
given set of annotations)
- Annotations of any complexity fail to capture every use case and have
to be extended to support new logic... in a language that's different from
the host language
- Annotations (in Java, but not Python) are visually ugly
- Annotations point up where the host language has failed.
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.
This temporary issue has persisted for 3+ years. I originally tried to do
mapper with annotations (taking a page from Java-land.) Because I needed to
drop to Java to define runtime accessible annotations, I went in search of
another mechanism and found that by and large, Scala's syntax and rich
language features make annotations unnecessary.
-
David Pollakfeeder.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
--
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
[Lift] Re: Why isn't this a trait in lift-json?
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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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, 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.eu wrote: 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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 8:06 PM, Timothy Perrett timo...@getintheloop.euwrote: 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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder:http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 if your inter-oping with some java framework that loves annotations. Yup, the sad truth. Cheers, Tim On 14 Sep 2009, at 19:22, 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 Perrett timo...@getintheloop.euwrote: 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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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, 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 8:06 PM, Timothy Perrett timo...@getintheloop.euwrote: 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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder:http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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! - Indrajit Raychaudhuriindraj...@gmail.com wrote: 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 8:06 PM, Timothy Perrett timo...@getintheloop.eu wrote: 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 i think there are not really any good technical reasons why it is we dont use java annotations - its mainly a general dislike. Cheers, Tim On Sep 14, 6:34 pm, Naftoli Gugenheim naftoli...@gmail.com 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.) 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. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder:http://groups.google.com/group/softpub -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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.
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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 (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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 with following case class structure.
case class Winner(@path(winner-id) id: Long, numbers: List[Int])
case class Lotto(id: Long, @path(winning-numbers) winningNumbers:
List[Int], winners: List[Winner],
@path(draw-date) drawDate: Option[Date])
Using a trait approach it would be something like:
case class Winner(id: Long with WinnerIdNominator, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int] with
WinningNumbersNominator, winners: List[Winner],
drawDate: Option[Date] with DrawDateNominator)
trait WinnerIdNominator extends Nominator {
def name = winner-id
}
trait WinningNumbersNominator extends Nominator {
def name = winning-numbers
}
trait DrawDateNominator extends Nominator {
def name = draw-date
}
Now, there's some problems.
1. Mixin a trait with a primitive fails:
scala case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
console:5: error: ambiguous reference to overloaded definition,
both method == in class Object of type (AnyRef)Boolean
and method == in class Long of type (Long)Boolean
match argument types (Long with WinnerIdNominator)
case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
2. How to get access to Nominator.name using reflection?
When extracting values we have json and type of target instance, in
this example classOf[Lotto]. It is not clear to me how those traits
should be reflected at runtime.
Cheers Joni
On Sep 14, 1:31 am, 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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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 Freemanfreeman.j...@gmail.com 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 extracting this with following case class structure.
case class Winner(@path(winner-id) id: Long, numbers: List[Int])
case class Lotto(id: Long, @path(winning-numbers) winningNumbers:
List[Int], winners: List[Winner],
@path(draw-date) drawDate: Option[Date])
Using a trait approach it would be something like:
case class Winner(id: Long with WinnerIdNominator, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int] with
WinningNumbersNominator, winners: List[Winner],
drawDate: Option[Date] with DrawDateNominator)
trait WinnerIdNominator extends Nominator {
def name = winner-id
}
trait WinningNumbersNominator extends Nominator {
def name = winning-numbers
}
trait DrawDateNominator extends Nominator {
def name = draw-date
}
Now, there's some problems.
1. Mixin a trait with a primitive fails:
scala case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
console:5: error: ambiguous reference to overloaded definition,
both method == in class Object of type (AnyRef)Boolean
and method == in class Long of type (Long)Boolean
match argument types (Long with WinnerIdNominator)
case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
2. How to get access to Nominator.name using reflection?
When extracting values we have json and type of target instance, in
this example classOf[Lotto]. It is not clear to me how those traits
should be reflected at runtime.
Cheers Joni
On Sep 14, 1:31?am, 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
-~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
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
case class Winner(id: Long, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int], winners: List
[Winner],
drawDate: Option[java.util.Date])
val json = parse(
{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] }
]
}
}
)
val json2 = json map {
case JField(winning-numbers, x) = JField(winningNumbers, x)
case JField(draw-date, x) = JField(drawDate, x)
case JField(winning-id, x) = JField(id, x)
case x = x
}
json2.extract[Lotto]
So, I can remove @path feature (and maybe reintroduce it when Scala
gets runtime visible annotations) if the community feels that Java
annotations should not be used.
Cheers Joni
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?
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 Freemanfreeman.j...@gmail.com 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 extracting this with following case class structure.
case class Winner(@path(winner-id) id: Long, numbers: List[Int])
case class Lotto(id: Long, @path(winning-numbers) winningNumbers:
List[Int], winners: List[Winner],
�...@path(draw-date) drawDate: Option[Date])
Using a trait approach it would be something like:
case class Winner(id: Long with WinnerIdNominator, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int] with
WinningNumbersNominator, winners: List[Winner],
drawDate: Option[Date] with DrawDateNominator)
trait WinnerIdNominator extends Nominator {
def name = winner-id
}
trait WinningNumbersNominator extends Nominator {
def name = winning-numbers
}
trait DrawDateNominator extends Nominator {
def name = draw-date
}
Now, there's some problems.
1. Mixin a trait with a primitive fails:
scala case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
console:5: error: ambiguous reference to overloaded definition,
both method == in class Object of type (AnyRef)Boolean
and method == in class Long of type (Long)Boolean
match argument types (Long with WinnerIdNominator)
case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
2. How to get access to Nominator.name using reflection?
When extracting values we have json and type of target instance, in
this example classOf[Lotto]. It is not clear to me how those traits
should be reflected at runtime.
Cheers Joni
On Sep 14, 1:31?am, 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,
