out with the old sexp in with new

[Tim Pigden]

Hi

I've been more or less successfully building some parsers and writers for xml and json based on the sexp examples that were in shapeless 2.10.x stream using LabelledTypeClassCompanion. I realise that this is always a perilous undertaking when the code is in a potential state of flux, but the new master stream has thrown everything out in favour of a "TypeClass replaced by more powerful Lazy and user level implicits."

So the question, simply, is "is the new form here to stay" or will another wholesale revision of this be taking place before 2.1? The next couple of days, being office holiday here, are an ideal time to work on it but I can't afford more time if another complete revamp is on its way

Tim

[Tim Pigden]

well it didn't take that long to get a better version with the new stuff.

I've created a github at

https://github.com/Optrak/json-shapeless-21

Unlike the sexp version my parse failures will throw exceptions. I couldn't use the Option return of the deserializer in sexp because I had to deal with optional fields of my own and couldn't tell the difference.

The production code will use scalaz Validation 

I may add an xml example based on the same principles later today

[Miles Sabin]

On Mon, Dec 29, 2014 at 7:43 PM, Tim Pigden <tim.p...@optrak.com> wrote:
> I've been more or less successfully building some parsers and writers for
> xml and json based on the sexp examples that were in shapeless 2.10.x stream
> using LabelledTypeClassCompanion. I realise that this is always a perilous
> undertaking when the code is in a potential state of flux, but the new
> master stream has thrown everything out in favour of a "TypeClass replaced
> by more powerful Lazy and user level implicits."

LabelledTypeClassCompanion is still there ... now it's implemented
entirely in terms of Lazy and (Labelled)Generic. If the
(Labelled)(Product)TypeClass API is flexible enough for your
application then you should continue to use it. If you need more room
to manoeuvre then working directly with Lazy and Generic is the way to
go.

> So the question, simply, is "is the new form here to stay" or will another
> wholesale revision of this be taking place before 2.1? The next couple of
> days, being office holiday here, are an ideal time to work on it but I can't
> afford more time if another complete revamp is on its way

You can safely assume that there will be at most bug fixes between now
and the 2.1.0 release.

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Tim Pigden]

xml example added. It's a bit more ugly due to the need to label nodes in "list" structures which you don't have in json arrays.

--
You received this message because you are subscribed to a topic in the Google Groups "Shapeless Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/shapeless-dev/OMA8JORMbuA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to shapeless-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England 
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

[yar....@gmail.com]

Hi Miles,

I cannot use a type that has more than one type parameter as a type parameter for LabelledTypeClassCompanion. I am working on a deserializer for Tim, and I need two additional type parameters to describe the source (think generic deserializer for json and xml). Is there a workaround?

[Miles Sabin]

On Mon, Jan 12, 2015 at 1:27 PM, <yar....@gmail.com> wrote:
> I cannot use a type that has more than one type parameter as a type
> parameter for LabelledTypeClassCompanion. I am working on a deserializer for
> Tim, and I need two additional type parameters to describe the source (think
> generic deserializer for json and xml). Is there a workaround?

Ahh ... understood. Yes, this is exactly the kind of scenario that
decomposing TypeClass into Lazy, (Labelled)Generic and vanilla
implicit resolution was intended to address. TypeClass is fairly
simple to use, but also somewhat inflexible. The primitives enable
pretty much anything, but some self-assembly is required.

From the examples Tim has already posted it looks like you're well
underway with that ... aside from the issue with case objects (I'll
take a look at that ASAP) are there any other obstacles in your way?

[yar....@gmail.com]

I'm trying to create an extractor of case class field names (call it HeaderBuilder) using LabelledTypeClass. This requires unnecessary HeaderBuilder instances for "atomic" types that constitute my case class, such as Int, String, Boolean and options of these (they all return Nil because I am only interested in field names, not values). Is there a nice way to get field names of a case class in shapeless without resorting to reflection? Or at least do away with those unnecessary HeaderBuilders?

Thank you for help.

[yar....@gmail.com]

Hi Miles,

I have run into a strange bug: a project using LabelledTypeClassCompanion fails to compile under certain conditions. I have a minimal example here: https://github.com/Optrak/shapeless21-macro-bug. The conditions are outlined in comments, but they are not accurate, because if one of them is not met, our larger project still fails to compile, but this smaller one compiles fine.