The protocol profile describes the data items, their attributes and where they
fit
in the overall structure.
The DSL is there to encode the representation from a human readable format
It's not per se specific to the medical field, the same trick could be used
for other standard business protocol
On Jun 18, 2012, at 5:35 PM, Softaddicts wrote:
> Lets talk a bit about my world here.
>
> We created a product to link medical equipments
> using a variety of protocols, some talk HL7, DICOM, others have proprietary
> means to
> access data from various places.
>
> From the start we chose the r
Lets talk a bit about my world here.
We created a product to link medical equipments
using a variety of protocols, some talk HL7, DICOM, others have proprietary
means to
access data from various places.
>From the start we chose the richest data representation, some of it came from
a few medical
On Monday, June 18, 2012 8:01:47 AM UTC-6, tbc++ wrote:
>
> > Isnt that just creating an api? Everywhere the old model exists you need
> to
> > call a function to create the desired data structure and this adds
> another
> > layer of complexity that needs maintained. Not all conversions are
I did not know about lazy map either… This might be exactly what I was
needed. Maps with referentially transparent properties rather than fields.
A way to make minor changes to map representation without adding an api in
advance, introducing breaking changes, redundant properties, or conver
I wan't aware of LazyMap! My solution so far was to attach functions
instead of values in maps. You 're still deferring the computation to
the underlying fn...in a sense it is a getter isn't it? and you can also
pass the map around to effectively get polymorphic behaviour on the fns
that accept
Yeah, I'm waiting for concrete example too.
By the way, if you really need to change :area from value to deferred
computation then you can just change your data structure implementation
from hash-map to lazy map (i.e. a map whose values are delays deref'd on
access). This would require changing
On Mon, Jun 18, 2012 at 3:37 PM, Kurt Harriger wrote:
>
> Representations are values in Clojure, they are not mixed with behaviors
> like in mainstream OO. It follows that, if your representation need to
> change, you can write a converter function (or two if you want to convert
> from and to the
> Isnt that just creating an api? Everywhere the old model exists you need to
> call a function to create the desired data structure and this adds another
> layer of complexity that needs maintained. Not all conversions are straight
> forward, may require additional context of whatever introducing
On Jun 18, 2012, at 2:09 AM, Christophe Grand wrote:
On Sun, Jun 17, 2012 at 8:59 PM, Kurt Harriger wrote:
>
> Data structure is an implementation detail...
>>
>
> It's not. Not in clojure. It is in OO, but clojure is not an OO language,
> so it's not an implementation detail in clojure.
>
>
> T
On Sun, Jun 17, 2012 at 8:59 PM, Kurt Harriger wrote:
>
> Data structure is an implementation detail...
>>
>
> It's not. Not in clojure. It is in OO, but clojure is not an OO language,
> so it's not an implementation detail in clojure.
>
>
> That is my point, representations SHOULD be considered i
On Jun 17, 2012, at 9:46 PM, Sean Corfield wrote:
> On Sun, Jun 17, 2012 at 8:06 PM, Kurt Harriger wrote:
>> One of the sayings I hear reiterated is "it is better to have 100 methods
>> that operate on one data structure than 10 methods that operate on 10 data
>> structures." Yet how is this di
On Jun 17, 2012, at 9:38 PM, Timothy Baldridge wrote:
>>> I have also found that clojure code lacks cohesion we hate objects so we
>>> are just going to throw everything into one large namespace and say we have
>>> none... In OO I might call this a god class? I don't know, I'm not sold
>>> ye
On Sun, Jun 17, 2012 at 8:06 PM, Kurt Harriger wrote:
> One of the sayings I hear reiterated is "it is better to have 100 methods
> that operate on one data structure than 10 methods that operate on 10 data
> structures." Yet how is this different from one large interface with a
> hundred methods
>> I have also found that clojure code lacks cohesion we hate objects so we are
>> just going to throw everything into one large namespace and say we have
>> none... In OO I might call this a god class? I don't know, I'm not sold
>> yet... but I'll keep watching.
That depends. In OOP we might
On Sunday, June 17, 2012 6:31:34 PM UTC-6, Sean Corfield wrote:
>
> On Sun, Jun 17, 2012 at 11:59 AM, Kurt Harriger
> wrote:
> > That is my point, representations SHOULD be considered implementation
> > details, because representations change... if you treat them as
> contracts
> > your cod
On Sun, Jun 17, 2012 at 1:32 PM, Kurt Harriger wrote:
> If you follow the
> hollywood principle you don't need getters... but you do need side-effects.
This might be where you're getting stuck then? Perhaps "the hollywood
principle" isn't the best approach? If you think it really requires
side-ef
On Sun, Jun 17, 2012 at 11:59 AM, Kurt Harriger wrote:
> That is my point, representations SHOULD be considered implementation
> details, because representations change... if you treat them as contracts
> your code will break everywhere, if you wrap them with abstractions your
> code will only nee
On Sunday, June 17, 2012 1:41:22 PM UTC-6, Vinzent wrote:
>
> That is my point, representations SHOULD be considered implementation
>> details, because representations change... if you treat them as contracts
>> your code will break everywhere, if you wrap them with abstractions your
>> code w
Your first lisp ? I suggest you immersed yourself in it. Clojure is my third.
Clojure is different from past languages because it allows features
that have existed for a number of years separately to coexist together nicely.
Many languages in the past have been created based on a couple of these
>
> That is my point, representations SHOULD be considered implementation
> details, because representations change... if you treat them as contracts
> your code will break everywhere, if you wrap them with abstractions your
> code will only need to change in one place...
>
As I mentioned ab
Sent from my iPhone
On Jun 17, 2012, at 12:43 PM, Vinzent wrote:
Data structure is an implementation detail...
>
It's not. Not in clojure. It is in OO, but clojure is not an OO language,
so it's not an implementation detail in clojure.
That is my point, representations SHOULD be considered im
>
> Data structure is an implementation detail...
>
It's not. Not in clojure. It is in OO, but clojure is not an OO language,
so it's not an implementation detail in clojure.
> interfaces are contracts, if the data representation changes in OO you
> need only change one class...
>
Well, bu
On Jun 17, 2012, at 10:45 AM, Vinzent wrote:
Yes it is... emails was not the best example in this case.. think the
> "area" example instead as this is single value rather than collection.
>
Well, I thought we've already came to the agreement that area is a
(polymorphic) function and it has nothi
>
> Yes it is... emails was not the best example in this case.. think the
> "area" example instead as this is single value rather than collection.
>
Well, I thought we've already came to the agreement that area is a
(polymorphic) function and it has nothing to do with structure of your
data,
On Sunday, June 17, 2012 9:09:23 AM UTC-6, Vinzent wrote:
>
> This still requires changing your code to @(:emails contact). If you use
(emails contact) you need change your code in only one place.
>>>
> The name "emails" implies that it's a sequence. Lazy sequence.
>
Yes it is... e
On Sunday, June 17, 2012 8:48:58 AM UTC-6, Vinzent wrote:
>
> Well, if those assertions are violated, you can't do anything with it
> anyway - you program is written wrong and you have to release new version
> which'll fix it.
>
Yes, but if data in your database become corrupt then you may nee
>
> A really good clojure specific example of data vs api is the discussion
>> regarding if the clojurescript analyzer should contain children or if
>> children should be a multimethod
>> https://groups.google.com/forum/m/?fromgroups#!topic/clojure-dev/vZLVKmKX0oc
>
>
By the way, I have read t
>
> This still requires changing your code to @(:emails contact). If you use
>>> (emails contact) you need change your code in only one place.
>>>
>>
The name "emails" implies that it's a sequence. Lazy sequence.
> Property is just the OO word for function, semantically they are the same.
Well, if those assertions are violated, you can't do anything with it
anyway - you program is written wrong and you have to release new version
which'll fix it.
воскресенье, 17 июня 2012 г., 1:41:17 UTC+6 пользователь Alex Baranosky
написал:
>
> To test for violations of those assertions, possi
On Jun 16, 2012, at 6:27 PM, Softaddicts wrote:
> 50 years of solid programming principles, OO being the Holy Grail ? :)
>
> I assume then that you programmed a lot in Simula-66 ? I did...
>
> For over 50 years, we made the same mistakes that Clojure attempts to
> correct. Most of the time new la
50 years of solid programming principles, OO being the Holy Grail ? :)
I assume then that you programmed a lot in Simula-66 ? I did...
For over 50 years, we made the same mistakes that Clojure attempts to
correct. Most of the time new languages repackaged the same flawed concepts
of the past, thi
--
Kurt Harriger
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Saturday, June 16, 2012 at 3:07 PM, Kurt Harriger wrote:
>
>
> On Saturday, June 16, 2012 1:28:21 PM UTC-6, Vinzent wrote:
> > > I agree, an explicit type field makes dispatching easy. However this
> > > data struc
On Saturday, June 16, 2012 1:28:21 PM UTC-6, Vinzent wrote:
>
> I agree, an explicit type field makes dispatching easy. However this data
>> structure returned by (http/get ... :as json) so if I want to add type
>> information I need to walk the tree and rewrite it. Not necessarily a bad
>>
On Saturday, June 16, 2012 12:26:34 PM UTC-6, Sean Corfield wrote:
>
> On Sat, Jun 16, 2012 at 10:58 AM, Kurt Harriger
> wrote:
> > How does one turn off pre/post conditions in production?
>
> (binding [*assert* false] (call-my-code))
>
>
> I agree with Sean
> > however and generally thin
To test for violations of those assertions, possibly due to wonky data that
only occurs in certain production-only circumstances.
--
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 p
>
> I actually think assertions should stay _on_ in production
>
Why? Could you please elaborate more on it?
--
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 memb
>
> I agree, an explicit type field makes dispatching easy. However this data
> structure returned by (http/get ... :as json) so if I want to add type
> information I need to walk the tree and rewrite it. Not necessarily a bad
> idea, but in some cases the only thing I need is the eTag and so
On Sat, Jun 16, 2012 at 10:58 AM, Kurt Harriger wrote:
> How does one turn off pre/post conditions in production?
(binding [*assert* false] (call-my-code))
> I agree with Sean
> however and generally think that assertions in production a bad thing.
I didn't say that. I said the question was a p
On Wednesday, June 13, 2012 2:52:15 AM UTC-6, Vinzent wrote:
>
> I do use pre-conditions where the test condition is simple, ie is this a
>> string? does the map have a :field-type? however I get a lot of my input
>> data from http requests as json which have similar structures but different
>
On Wed, Jun 13, 2012 at 1:52 AM, Vinzent wrote:
> Why do you care about computational expensiveness of pre and post
> conditions? They'll be turned off in production anyway.
I think that's a philosophical question :)
> In clojure, structure of your map is a part of the contract. It's not an
> im
>
> I do use pre-conditions where the test condition is simple, ie is this a
> string? does the map have a :field-type? however I get a lot of my input
> data from http requests as json which have similar structures but different
> semantics, so I often do not have preconditions where type is n
On Tuesday, June 12, 2012 2:18:03 AM UTC-6, Christophe Grand wrote:
>
> Hi,
>
> To contrast our experiences of the language and the different approaches
> to deal with some problems:
>
> On Sun, Jun 10, 2012 at 4:47 AM, Kurt Harriger wrote:
>
>> Many will say that side-effecting functions are m
Hi,
To contrast our experiences of the language and the different approaches to
deal with some problems:
On Sun, Jun 10, 2012 at 4:47 AM, Kurt Harriger wrote:
> Many will say that side-effecting functions are more difficult to test
> then pure functions... However after writing about 4000 lines
Von: *David Jacobs *
> An: *clojure@googlegroups.com*
> Gesendet: *Sa, 09 Jun 2012, 23:08:21 MESZ*
> Betreff: *Re: Doseq, map-style
>
> Thanks, guys.
>
> I know there are easy ways to implement what I want. However, I'm more
> curious as to why the language itself doesn
This is good stuff. I've certainly felt the same way about FP at some
points--for me, Clojure really illuminates why people thought OO was such a
good thing 15 years ago. Let me know if you write that blog post.
On Saturday, June 9, 2012 7:47:47 PM UTC-7, Kurt Harriger wrote:
>
>
> You could a
liche Nachricht-
Von: David Jacobs
An: clojure@googlegroups.com
Gesendet: Sa, 09 Jun 2012, 23:08:21 MESZ
Betreff: Re: Doseq, map-style
Thanks, guys.
I know there are easy ways to implement what I want. However, I'm more curious
as to why the language itself doesn't support this style
I agree that it probably doesn't need to be a macro (your second suggestion was
my first inclination).
I didn't realize doseq took keyword options, that's good to know.
On Saturday, June 9, 2012 at 7:51 PM, Walter Tetzner wrote:
> > Is there a philosophical difference underlying the syntax
>
> Is there a philosophical difference underlying the syntax difference
> (doseq [elem coll] (f coll)) and (each f coll)?
>
`doseq' is the side-effecty version of `'for', not map. It lets you do
things like
user> (doseq [x (range 100)
:while (< x 20)
:when (even? x)]
You could also (dorun (map f coll))
It is actually interesting you brought this up as I was recently
contrasting the OO principle "tell don't ask" with the functional way of
doing things. In OO a void method taking a visitor is preferred over
return values. One could perhaps say that (doru
Thanks, guys.
I know there are easy ways to implement what I want. However, I'm more curious
as to why the language itself doesn't support this style of mapping
side-effects.
In other words, why does doseq not follow map's lead here. Is there a
philosophical difference underlying the syntax di
I'd just use doseq.
--
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 unsubscribe from this group,
I just saw this has been already answered! I apologise for the noise!
Jim
On 09/06/12 16:45, Jim - FooBar(); wrote:
Why not make it yourself? Something like this perhaps?
(defmacro doeach [f coll]
`(doseq [x# ~coll] (~f x#)))
Itis good if you name it "doeach" instead of each to imply
side-ef
Why not make it yourself? Something like this perhaps?
(defmacro doeach [f coll]
`(doseq [x# ~coll] (~f x#)))
Itis good if you name it "doeach" instead of each to imply side-effects
(just like doseq)...
Hope that helps...
Jim
On 08/06/12 04:32, David Jacobs wrote:
I would love to have a ve
On Sat, Jun 9, 2012 at 6:13 PM, Meikel Brandmeyer wrote:
> the doseq has the additional benefit of its ugliness which makes
> side-effects stand out. ;)
+1
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the Google
Groups "Clo
Hi,
the doseq has the additional benefit of its ugliness which makes side-effects
stand out. ;)
Kind regards
Meikel
-Ursprüngliche Nachricht-
Von: Sean Corfield
An: clojure@googlegroups.com
Gesendet: Sa, 09 Jun 2012, 04:50:53 MESZ
Betreff: Re: Doseq, map-style
On Thu, Jun 7, 2012 at
> I would love to have a version of doseq that works like map (similar to
> "each" in other dynamic languages). In other words, instead of (doseq [log
> logs] (println log)), I would say something like (each println logs).
>
> Is there a built-in Clojure method that works like this?
Since Clojure
On Thu, Jun 7, 2012 at 8:32 PM, David Jacobs wrote:
> I would love to have a version of doseq that works like map (similar to
> "each" in other dynamic languages). In other words, instead of (doseq [log
> logs] (println log)), I would say something like (each println logs).
Since that implies a s
On Fri, Jun 8, 2012 at 9:54 AM, Allen Johnson wrote:
> Combine map with dorun and you get the same effect:
>
> (dorun (map println logs))
>
> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
>
> Allen
>
> On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs wrote:
>> I would lo
Combine map with dorun and you get the same effect:
(dorun (map println logs))
http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
Allen
On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs wrote:
> I would love to have a version of doseq that works like map (similar to
> "each
I would love to have a version of doseq that works like map (similar to
"each" in other dynamic languages). In other words, instead of (doseq [log
logs] (println log)), I would say something like (each println logs).
Is there a built-in Clojure method that works like this?
--
You received this
61 matches
Mail list logo
