Re: Struct vs. Record: Now and Future

2011-01-30 Thread Stuart Sierra
This is not solvable in the most general case. Java serialization tries really hard to be a completely generic format, but when you have a large graph of complex objects it becomes unwieldy and inefficient. Clojure's pr/read will suffice if you restrict yourself to types that can be read by the

Re: Struct vs. Record: Now and Future

2011-01-28 Thread Ken Wesson
On Fri, Jan 28, 2011 at 6:50 PM, Mark Engelberg wrote: > > > On Fri, Jan 28, 2011 at 2:09 PM, Stuart Sierra > wrote: >> >> Neither defrecords nor structmaps can be printed and read back by the >> Clojure reader.  You can work around this by converting them to plain maps >> or using a custom print

Re: Struct vs. Record: Now and Future

2011-01-28 Thread Mark Engelberg
On Fri, Jan 28, 2011 at 2:09 PM, Stuart Sierra wrote: > Neither defrecords nor structmaps can be printed and read back by the > Clojure reader. You can work around this by converting them to plain maps > or using a custom printer that prints the constructor forms. > So if I don't care about huma

Re: Struct vs. Record: Now and Future

2011-01-28 Thread Stuart Sierra
defrecord is preferred over structmap in all cases going forward. Neither defrecords nor structmaps can be printed and read back by the Clojure reader. You can work around this by converting them to plain maps or using a custom printer that prints the constructor forms. Many people have reques

Re: Struct vs. Record: Now and Future

2011-01-28 Thread David McNeil
> While this serialization has been fine for most of my needs I have quite > often wanted to be able to use *print-dup* since binary serialization > seemed overkill in those cases.  Hopefully something like defrecord2 > gets added to clojure at some point to make dealing with records more > pleasan

Re: Struct vs. Record: Now and Future

2011-01-28 Thread Meikel Brandmeyer
Hi, On 28 Jan., 13:46, Chas Emerick wrote: > I don't think it's obvious whether any particular serialization > mechanism is generally better or worse than another without knowing > details about a particular context.  *print-dup*'s (and others') > generally human-readable representations and dyn

Re: Struct vs. Record: Now and Future

2011-01-28 Thread Chas Emerick
On Jan 27, 2011, at 10:41 PM, Ben Mabey wrote: > On 1/27/11 7:24 PM, Ken Wesson wrote: >> On Thu, Jan 27, 2011 at 6:24 PM, Mark Engelberg >> wrote: >>> Records don't have serialization yet, do they? >> user=> (defrecord Foo [n]) >> user.Foo >> user=> ((supers Foo) java.io.Serializable) >> jav

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Ben Mabey
On 1/27/11 8:41 PM, Ben Mabey wrote: On 1/27/11 7:24 PM, Ken Wesson wrote: On Thu, Jan 27, 2011 at 6:24 PM, Mark Engelberg wrote: Records don't have serialization yet, do they? user=> (defrecord Foo [n]) user.Foo user=> ((supers Foo) java.io.Serializable) java.io.Serializable Looks like t

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Ben Mabey
On 1/27/11 7:24 PM, Ken Wesson wrote: On Thu, Jan 27, 2011 at 6:24 PM, Mark Engelberg wrote: Records don't have serialization yet, do they? user=> (defrecord Foo [n]) user.Foo user=> ((supers Foo) java.io.Serializable) java.io.Serializable Looks like they do. I've been serializing/serial

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Mark Engelberg
So what's the recommended way to serialize, then? It used to be that binding *print-dup* to true was the recommended way, but last I checked, that technique didn't work for things like records. Remember, it's not just about serializing an individual record, it's about serializing an arbitrary pie

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Ken Wesson
On Thu, Jan 27, 2011 at 6:24 PM, Mark Engelberg wrote: > Records don't have serialization yet, do they? user=> (defrecord Foo [n]) user.Foo user=> ((supers Foo) java.io.Serializable) java.io.Serializable Looks like they do. And if they didn't, (defrecord Foo [n] java.io.Serializable) would p

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Lee Spector
On Jan 27, 2011, at 6:02 PM, Meikel Brandmeyer wrote: > > I kind of miss the difference in ugliness. If you want default values for > your structs you also need a factory function. So unless you write the > factory function for each struct, you'll also need a defstructx. > records will be the

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Mark Engelberg
Records don't have serialization yet, do they? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To u

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Meikel Brandmeyer
Hi, Am 27.01.2011 um 23:08 schrieb OGINO Masanori: > It seems ugly for someone using them like function frequently, but > cool for someone using them like function rarely. Consider this: (defn to-factory [record] (-> record name (.replaceAll "([a-z0-9])([A-Z])" "$1-$2") .toLower

Re: Struct vs. Record: Now and Future

2011-01-27 Thread OGINO Masanori
Hello. Sorry for miss-operation resulting in meaningless post. > Extending your record to IFn is easy, just add the invoke method. Oh, it's really easy. It seems ugly for someone using them like function frequently, but cool for someone using them like function rarely. I also read Ken's code, a

Re: Struct vs. Record: Now and Future

2011-01-27 Thread David Nolen
2011/1/27 OGINO Masanori > Hello. > > Well, record lacks some features in struct for now, I see. > And "defstructs implement IFn" means that we can use struct in the > places need callbacks but record can't, right? > > Thank you. > > -- > Name: OGINO Masanori (荻野 雅紀) > E-mail: masanori.og...@gma

Re: Struct vs. Record: Now and Future

2011-01-27 Thread OGINO Masanori
Hello. Well, record lacks some features in struct for now, I see. And "defstructs implement IFn" means that we can use struct in the places need callbacks but record can't, right? Thank you. -- Name: OGINO Masanori (荻野 雅紀) E-mail: masanori.og...@gmail.com -- You received this message because

Re: Struct vs. Record: Now and Future

2011-01-27 Thread OGINO Masanori
2011/1/27, Lee Spector : > > There was a recent thread on this. Some of the issues that were raised (and > for which workarounds were presented) were slot defaults, keyword args to > struct-map, and the fact that defstructs implement IFn. I had also found it > more elegant to write a macro or two t

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Ken Wesson
On Thu, Jan 27, 2011 at 9:34 AM, Lee Spector wrote: > > There was a recent thread on this. Some of the issues that were raised (and > for which workarounds were presented) were slot defaults, keyword args to > struct-map, and the fact that defstructs implement IFn. I had also found it > more el

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Lee Spector
There was a recent thread on this. Some of the issues that were raised (and for which workarounds were presented) were slot defaults, keyword args to struct-map, and the fact that defstructs implement IFn. I had also found it more elegant to write a macro or two to expand into struct-related co

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Meikel Brandmeyer
Hi, On 27 Jan., 14:47, Nick Zbinden wrote: > Structs are nicer to work with. We should get all the nice stuff you > can do with structs to records then we can mark structs as dublicated. What in particular do you find lacking with records? Sincerely Meikel -- You received this message becaus

Re: Struct vs. Record: Now and Future

2011-01-27 Thread Nick Zbinden
Structs are nicer to work with. We should get all the nice stuff you can do with structs to records then we can mark structs as dublicated. On Jan 27, 2:43 pm, OGINO Masanori wrote: > Hello. > > I have two questions: > > 1. Is there any reason why we should use struct rather than record in > new