Re: defrecord == premature optimization?

2016-02-08 Thread Terje Dahl
To comment my own question some years and a bit of experience later: I would say that, just like with type-hinting: hold of as long as possible. Only when you find yourself adding to a map something like: {:type Person} is it time to consider using a Record in stead. And of course also if you wou

Re: defrecord == premature optimization?

2011-09-07 Thread Brian Goslinga
On Sep 7, 9:07 am, Stefan Kamphausen wrote: > Hi, > > yeah, maybe I should have chosen my words more wisely.  I think it comes > from my CL background where you can > > (declare (optimize (speed 3) (safety 0)) > > to achieve this behavior. Not to be nitpicking here. An Exception is > obviously 'sa

Re: defrecord == premature optimization?

2011-09-07 Thread Herwig Hochleitner
2011/9/7 Nick Zbinden > Solving the problem is easy. Just implment it by expaning the interface zu >set type. > The question we could ask know is why it it not included in the > standart record? That was my question precisely. Or at least how I meant it. Also, Stuart answered it precisely. > Re

Re: defrecord == premature optimization?

2011-09-07 Thread Nick Zbinden
There are some simple things you have to understand when you want to know why you cant have: (defrecord Person [foo bar]) ((Person. "1" "2") :foo) In Clojure something after a "(" gets called as a function. A function is something that can be "applied" (not the "apply" function. "applied" is now i

Re: Aw: Re: defrecord == premature optimization?

2011-09-07 Thread Stefan Kamphausen
Hi, yeah, maybe I should have chosen my words more wisely. I think it comes from my CL background where you can (declare (optimize (speed 3) (safety 0)) to achieve this behavior. Not to be nitpicking here. An Exception is obviously 'safer' than a silent truncation and then the decision betwe

Aw: Re: defrecord == premature optimization?

2011-09-07 Thread Meikel Brandmeyer (kotarak)
Hi, Am Mittwoch, 7. September 2011 15:21:23 UTC+2 schrieb Stefan Kamphausen: > > > user=> (* 100 100) > 1 > > in 1.3.0 (MASTER a few days ago) > user=> (* 100 100) > ArithmeticException integer over

Re: defrecord == premature optimization?

2011-09-07 Thread Stefan Kamphausen
Hi, On Wednesday, September 7, 2011 3:02:00 PM UTC+2, Meikel Brandmeyer (kotarak) wrote: > > Hi, > > Am Mittwoch, 7. September 2011 14:05:57 UTC+2 schrieb Stefan Kamphausen: >> >> the explanation why speed is the default and not safety (if I may >> summarize the direction 1.3 took like that) >>

Re: defrecord == premature optimization?

2011-09-07 Thread Meikel Brandmeyer (kotarak)
Hi, Am Mittwoch, 7. September 2011 14:05:57 UTC+2 schrieb Stefan Kamphausen: > > the explanation why speed is the default and not safety (if I may summarize > the direction 1.3 took like that) > In which way is 1.3 less safe than 1.2? Sincerely Meikel -- You received this message because yo

Re: defrecord == premature optimization?

2011-09-07 Thread Alasdair MacLeod
> AFAIK there a lots of well designed things in Clojure which reflect deep > thinking and a strong reasoning.   I can imagine, that many people would > like to read those things in one place, probably rather close to the > Rationale for Clojure itself.  Something like Design Principles. > > But the

Re: defrecord == premature optimization?

2011-09-07 Thread Stefan Kamphausen
Hi, a little off-topic ... On Wednesday, September 7, 2011 1:12:05 AM UTC+2, stuart@gmail.com wrote: > > This is by design. Function position indicates that the data structure is a > collection, not a (logical) record. > AFAIK there a lots of well designed things in Clojure which reflect d

Re: defrecord == premature optimization?

2011-09-06 Thread Stuart Halloway
> Am Dienstag, 6. September 2011 schrieb Alasdair MacLeod : > I guess the only gotcha is if a function treats the record as a map > and > tries to access a field by putting the record in function position: > > user=> (defrecord Person [first last]) > user.Person > user=> ((Person. "Joe" "Bloggs"):

Re: defrecord == premature optimization?

2011-09-06 Thread Herwig Hochleitner
Am Dienstag, 6. September 2011 schrieb Alasdair MacLeod : > > I guess the only gotcha is if a function treats the record as a map > and > tries to access a field by putting the record in function position: > > user=> (defrecord Person [first last]) > user.Person > user=> ((Person. "Joe" "Bloggs"):f

Re: defrecord == premature optimization?

2011-09-06 Thread Alasdair MacLeod
> The types created by defrecord implement the same interfaces as maps, > so they can be used as maps. I guess the only gotcha is if a function treats the record as a map and tries to access a field by putting the record in function position: user=> (defrecord Person [first last]) user.Person use

Re: defrecord == premature optimization?

2011-09-05 Thread Brian Goslinga
On Sep 5, 8:46 am, Terje Dahl wrote: > Ref:  Stuart Halloway's talk: "Simplicity": > > http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694 > > Found via reading list:http://clojure.com/reading.html) > > At one point in his talk he states that defrecord is in fact basically > "docu

defrecord == premature optimization?

2011-09-05 Thread Terje Dahl
Ref: Stuart Halloway's talk: "Simplicity": http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694 Found via reading list: http://clojure.com/reading.html ) At one point in his talk he states that defrecord is in fact basically "documented, named [typed] structure". (as opposed to