Yes, I agree.
Thanks for helping me to clarify my thoughts on this.
On Thursday, 11 April 2013 02:40:23 UTC+1, Cedric Greevey wrote:
>
> Let me clarify. If the library's designed to interoperate specifically
> with a particular record type, it should be designed with knowledge of the
> base key
Let me clarify. If the library's designed to interoperate specifically with
a particular record type, it should be designed with knowledge of the base
keys. Even then, its own keys should be ns-qualified. And it can't assume
the set of base keys won't grow in a future version of the record type. Bu
If a library adds keys to foreign maps, those keys should be ns qualified
IMO.
On Wed, Apr 10, 2013 at 1:24 PM, Simon Katz wrote:
> On Wednesday, 10 April 2013 21:08:22 UTC+1, Cedric Greevey wrote:
>
>> If a third-party library is storing things in your defrecord, it behooves
>> its author to k
On Wednesday, 10 April 2013 21:08:22 UTC+1, Cedric Greevey wrote:
> If a third-party library is storing things in your defrecord, it behooves
> its author to know what that record's predefined keys are.
>
Um, I don't think I agree. The library might be doing something very
generic and have no r
If a third-party library is storing things in your defrecord, it behooves
its author to know what that record's predefined keys are.
In fact, if a third-party library is putting (its own, rather than
caller-supplied) keys into caller-supplied maps, it behooves it to use
qualified keys. :)
On Wed
I agree that things will be fine if the third-party code uses
namespace-qualified keywords, but there can be clashes if the third-party
library uses simple keywords.
On Wednesday, 10 April 2013 20:55:18 UTC+1, Cedric Greevey wrote:
>
> I don't think that creates a need for qualified defrecord "b
I don't think that creates a need for qualified defrecord "base keys" (the
[x y z] in your example) though. Those keys are all from one origin: the
piece of code with the defrecord itself in it. That piece is defining the
data type and it stands to reason that it be privileged to specify
unqualifie
Yes. That concept of a promiscuous map (great name) is what I'm trying to
get at.
On Wednesday, 10 April 2013 20:30:52 UTC+1, Cedric Greevey wrote:
>
> The main use for qualified keywords that occurs to me is if you have a
> "promiscuous map" that will be holding key/value pairs submitted by
>
On Wed, Apr 10, 2013 at 2:13 PM, Jim foo.bar wrote:
> On 10/04/13 14:03, Simon Katz wrote:
>
>> Second, Clojure supports namespace-qualified keywords, presumably because
>> it's possible that different libraries might want to use the same keyword
>> for different purposes.
>>
>
> I don't think th
Or keys your library adds to a var, for instance.
On Wed, Apr 10, 2013 at 12:30 PM, Cedric Greevey wrote:
> The main use for qualified keywords that occurs to me is if you have a
> "promiscuous map" that will be holding key/value pairs submitted by
> multiple pieces of code of distinct origins.
The main use for qualified keywords that occurs to me is if you have a
"promiscuous map" that will be holding key/value pairs submitted by
multiple pieces of code of distinct origins. A big registry of preferences
that can be added to by plugins would be an example, with qualified
keywords making i
On 10/04/13 14:03, Simon Katz wrote:
Second, Clojure supports namespace-qualified keywords, presumably
because it's possible that different libraries might want to use the
same keyword for different purposes.
I don't think that is the reason for having namespace-qualified
keywords...different
Replying to myself...
Hmmm, of course, defining that function wouldn't solve the problem of
clashes.
On Wednesday, 10 April 2013 14:03:47 UTC+1, Simon Katz wrote:
>
> I'm wondering how two things fit together (and I suspect they don't).
>
> First, if I define a record type, e.g.
> (defrecord F
13 matches
Mail list logo
