Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-27 Thread Christian Schuhegger
Thanks for that recommendation, I definitely like that proposal! I guess the drawback is then that destructuring will not be safe. I have to think some more time about it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send

Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-26 Thread Steve Miner
Creating your own Closed Map type would be the object-oriented approach. One downside is that a closed-map feels like a normal map, but can't be safely substituted for most maps because of the booby-trap when using assoc (etc.) with a new key. It doesn't really fulfill the map contract

Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-26 Thread Ken Wesson
On Tue, Apr 26, 2011 at 1:06 PM, Steve Miner stevemi...@gmail.com wrote: Creating your own Closed Map type would be the object-oriented approach.   One downside is that a closed-map feels like a normal map, but can't be safely substituted for most maps because of the booby-trap when using

Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-23 Thread Christian Schuhegger
Thanks for all of your answers, but I think for my use cases the approach proposed by Justin looks most promising. I'll implement my own closed map. Another idea that come to my mind was that a closed map is actually a Java Bean without behaviour. Perhaps the closed map could be implemented by

Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-22 Thread Justin Kramer
I should be straightforward to implement a closed map (or record) yourself using deftype. It could implement all the same interfaces as Clojure's built-in maps, ensuring compatibility with assoc and such. Here's an example of a map variant implemented using deftype:

Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-22 Thread Armando Blancas
With regard to mistyped keys in general, a simple option is to use named keys; then the compiler will flag undefined ones. (def k :key) ... (k m) On Apr 21, 10:44 pm, Christian Schuhegger christian.schuheg...@gmail.com wrote: I am taking up a discussion from

Re: closed maps / reducing runtime errors due to mistyped keywords

2011-04-22 Thread Alex Miller
This defrecord2 implementation has key checks on construction but still allows you to forcibly insert other keys after the fact. I believe the proposed defrecord enhancements for 1.3 may have some similar opportunities. You could use your own assoc that checked the known record keys too.

closed maps / reducing runtime errors due to mistyped keywords

2011-04-21 Thread Christian Schuhegger
I am taking up a discussion from 2010: https://groups.google.com/group/clojure/browse_frm/thread/60dff89149c3d2e6/ I would prefer if it would be possible to define closed maps, e.g. maps that allow only a certain set of keywords, both for get and set (like in assoc, assoc-in, update-in, ...). It

reducing runtime errors due to mistyped keywords

2010-04-22 Thread Istvan Devai
Hi! In general, what to give greater attention if I'm getting lots of runtime errors due to mistyped keywords? (eg. I'm referencing a map where the keyword is non-existent and this nil value goes deep down into my code where it is very hard to see that this was caused by a non-existing map

Re: reducing runtime errors due to mistyped keywords

2010-04-22 Thread Jason Wolfe
Hi Istvan, I've run into this a fair bit too. To catch such problems (at runtime), I sprinkle my code with (safe-get m :key) in key places, rather than (:key m) or (m :key) or (get m :key). safe-get: (defmacro lazy-get Like get but lazy about evaluating default [m k d] `(if-let [pair#