Re: Feedback on datafy/nav project

[Derek Troy-West]

Hi Dimitris.

I think your library is an excellent idea. Like the other replies I'd 
prefer if it used Datafiable.

Would you consider adopting an explicit options map instead of the jdt/now! 
varags destructuring? I'm not sure if that style is adopted throughout, but 
in general I prefer maps to the syntactic sugar.

Finally, just a suggestion that 'objectify' might be a bit more explicit in 
intent to 'undatafy'.

I look forward to getting it in the REPL once it's up on clojars, thanks!

On Saturday, 1 February 2020 08:50:31 UTC+11, Jim foo.bar wrote:
>
> Sean, 
>
> I've already done that ;)
>
> I will publish to clojars either this weekend or the next - I just want to 
> add some more tests...
>
>
> On 31/01/2020 21:34, Sean Corfield wrote:
>
> Dimitris,
>
>  
>
> As a follow-up to Alex’s comments: if you change your lib to extend the 
> clojure.datafy version, I’ll almost certainly use your library 😊 
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *dimitris 
> *Sent: *Friday, January 31, 2020 1:23 PM
> *To: *clo...@googlegroups.com 
> *Subject: *Re: Feedback on datafy/nav project
>
>  
>
> Ok, thanks a million Alex
>
>  
>
> On 31/01/2020 21:13, Alex Miller wrote:
>
> Datafiable is not special, the guidelines (recently refreshed with Rich's 
> input at https://clojure.org/reference/protocols#_guidelines_for_extension) 
> still make sense, but are still just guidelines for your thinking not Laws 
> whose breakage will land you in Clojure Jail.
>
>  
>
> If you want to make protocol extensions for java time objects to 
> datafiable and put it in a lib, go for it. No one is making anyone else use 
> it. Maybe some day we'll do that in core, maybe not.
>
>  
>
> I'm certain that copying Datafiable to your own version however would lead 
> only to a) confusion and b) a certainty that no one else would actually use 
> it, and that seems like a waste of time.
>
>  
>
>
> On Friday, January 31, 2020 at 1:24:09 PM UTC-6, Jim foo.bar wrote: 
>
> I tend to agree with you in where the benefit is - it's just that the way 
> the protocol docs are phrased, and some of the language used in that 
> mailing discussion from 10 years ago (from authoritative sources like Rich 
> and Stuart), implies that *no library is to extend clojure.core protocols 
> to core Java objects*, and that only Clojure itself is allowed do that. 
> The example Stuart gave back then with the english/spelling-corrector VS 
> spanish/spelling-corrector is pretty telling...
>
> Could it perhaps be the case that `Datafiable` is somewhat special in 
> that, it was conceived for the purpose of open extension by third parties, 
> and that the protocol extension guidelines don't really apply to it (or 
> perhaps not as strictly)?  
>
>  
>
> Thanks for taking the time :)
>
> Dimitris
>
>  
>
> On 31/01/2020 01:23, Sean Corfield wrote:
>
> If your library is intended specifically to provide the ability to 
> datafy/nav java.time objects then it is something optional that users can 
> choose to opt into.
>
>  
>
> The section you meant to link to 
> https://clojure.org/reference/protocols#_guidelines_for_extension says: “To 
> minimize conflicts, consider these guidelines”
>
>  
>
> So they’re a) guidelines and b) just given as a caution to minimize 
> conflicts.
>
>  
>
> There are libraries out there already that exist specifically to give 
> users the option to extend protocols from one library (such as 
> clojure.java.jdbc or next.jdbc) to Java types to provide customized 
> behavior, above and beyond the “base versions for common targets” 
> mentioned in that section provided by the original library.
>
>  
>
> I see benefit in libraries that extend Clojure’s datafy/nav to new domains 
> as a narrow purpose that users can opt into. I see much less benefit in 
> providing the same protocols and function names that core already includes, 
> targeted to new types, in an isolated way such as this. Perhaps that is 
> because I’m already using datafy/nav and I find their utility is enhanced 
> by being extended to other Java types?
>
>  
>
> Yes, if multiple people write multiple libraries A, B, C that extend 
> datafy/nav to java.time types and then other libraries X, Y, Z start 
> pulling in those extenders, consumers of X, Y, Z can be in trouble.
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *dimitris 
> *Sent: *Thursday, January 30, 2020 9:58 AM
> *To: *clo...@googlegroups.com 
> *Subject: *Re: Feedback on datafy/nav project
>
>  
>
> Well, the official Clojure guidelines are to NOT extend protocols, unless 
> you own either the protocol of the type(s) [1].
>
> In particular these lines:
>
> *If you are a library developer, you should not extend if you own neither 
> the

Re: Feedback on datafy/nav project

[dimitris]

Sean,

I've already done that ;)

I will publish to clojars either this weekend or the next - I just want 
to add some more tests...



On 31/01/2020 21:34, Sean Corfield wrote:


Dimitris,

As a follow-up to Alex’s comments: if you change your lib to extend 
the clojure.datafy version, I’ll almost certainly use your library 😊


Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

*From: *dimitris 
*Sent: *Friday, January 31, 2020 1:23 PM
*To: *clojure@googlegroups.com 
*Subject: *Re: Feedback on datafy/nav project

Ok, thanks a million Alex

On 31/01/2020 21:13, Alex Miller wrote:

Datafiable is not special, the guidelines (recently refreshed with
Rich's input at
https://clojure.org/reference/protocols#_guidelines_for_extension)
still make sense, but are still just guidelines for your thinking
not Laws whose breakage will land you in Clojure Jail.

If you want to make protocol extensions for java time objects to
datafiable and put it in a lib, go for it. No one is making anyone
else use it. Maybe some day we'll do that in core, maybe not.

I'm certain that copying Datafiable to your own version however
would lead only to a) confusion and b) a certainty that no one
else would actually use it, and that seems like a waste of time.


On Friday, January 31, 2020 at 1:24:09 PM UTC-6, Jim foo.bar wrote:

I tend to agree with you in where the benefit is - it's just
that the way the protocol docs are phrased, and some of the
language used in that mailing discussion from 10 years ago
(from authoritative sources like Rich and Stuart), implies
that /no library is to extend clojure.core protocols to core
Java objects/, and that only Clojure itself is allowed do
that. The example Stuart gave back then with the
english/spelling-corrector VS spanish/spelling-corrector is
pretty telling...

Could it perhaps be the case that `Datafiable` is somewhat
special in that, it was conceived for the purpose of open
extension by third parties, and that the protocol extension
guidelines don't really apply to it (or perhaps not as strictly)?

Thanks for taking the time :)

Dimitris

On 31/01/2020 01:23, Sean Corfield wrote:

If your library is intended specifically to provide the
ability to datafy/nav java.time objects then it is
something optional that users can choose to opt into.

The section you meant to link to
https://clojure.org/reference/protocols#_guidelines_for_extension
says: “To minimize conflicts, consider these guidelines”

So they’re a) guidelines and b) just given as a caution to
minimize conflicts.

There are libraries out there already that exist
specifically to give users the option to extend protocols
from one library (such as clojure.java.jdbc or next.jdbc)
to Java types to provide customized behavior, above and
beyond the “base versions for common targets” mentioned in
that section provided by the original library.

I see benefit in libraries that extend Clojure’s
datafy/nav to new domains as a narrow purpose that users
can opt into. I see much less benefit in providing the
same protocols and function names that core already
includes, targeted to new types, in an isolated way such
as this. Perhaps that is because I’m already using
datafy/nav and I find their utility is enhanced by being
extended to other Java types?

Yes, if multiple people write multiple libraries A, B, C
that extend datafy/nav to java.time types and then other
libraries X, Y, Z start pulling in those extenders,
consumers of X, Y, Z can be in trouble.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

*From: *dimitris 
*Sent: *Thursday, January 30, 2020 9:58 AM
*To: *clojure@googlegroups.com

*Subject: *Re: Feedback on datafy/nav project

Well, the official Clojure guidelines are to NOT extend
protocols, unless you own either the protocol of the
type(s) [1].

In particular these lines:

/If you are a library developer, you should not extend if
you own neither the protocol nor the target./

/You should take particular care when extending protocols
  

RE: Feedback on datafy/nav project

[Sean Corfield]

Dimitris,

As a follow-up to Alex’s comments: if you change your lib to extend the 
clojure.datafy version, I’ll almost certainly use your library 😊 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: dimitris
Sent: Friday, January 31, 2020 1:23 PM
To: clojure@googlegroups.com
Subject: Re: Feedback on datafy/nav project

Ok, thanks a million Alex

On 31/01/2020 21:13, Alex Miller wrote:
Datafiable is not special, the guidelines (recently refreshed with Rich's input 
at https://clojure.org/reference/protocols#_guidelines_for_extension) still 
make sense, but are still just guidelines for your thinking not Laws whose 
breakage will land you in Clojure Jail.

If you want to make protocol extensions for java time objects to datafiable and 
put it in a lib, go for it. No one is making anyone else use it. Maybe some day 
we'll do that in core, maybe not.

I'm certain that copying Datafiable to your own version however would lead only 
to a) confusion and b) a certainty that no one else would actually use it, and 
that seems like a waste of time.


On Friday, January 31, 2020 at 1:24:09 PM UTC-6, Jim foo.bar wrote: 
I tend to agree with you in where the benefit is - it's just that the way the 
protocol docs are phrased, and some of the language used in that mailing 
discussion from 10 years ago (from authoritative sources like Rich and Stuart), 
implies that no library is to extend clojure.core protocols to core Java 
objects, and that only Clojure itself is allowed do that. The example Stuart 
gave back then with the english/spelling-corrector VS 
spanish/spelling-corrector is pretty telling...
Could it perhaps be the case that `Datafiable` is somewhat special in that, it 
was conceived for the purpose of open extension by third parties, and that the 
protocol extension guidelines don't really apply to it (or perhaps not as 
strictly)?  

Thanks for taking the time :)
Dimitris

On 31/01/2020 01:23, Sean Corfield wrote:
If your library is intended specifically to provide the ability to datafy/nav 
java.time objects then it is something optional that users can choose to opt 
into.
 
The section you meant to link to 
https://clojure.org/reference/protocols#_guidelines_for_extension says: “To 
minimize conflicts, consider these guidelines”
 
So they’re a) guidelines and b) just given as a caution to minimize conflicts.
 
There are libraries out there already that exist specifically to give users the 
option to extend protocols from one library (such as clojure.java.jdbc or 
next.jdbc) to Java types to provide customized behavior, above and beyond the 
“base versions for common targets” mentioned in that section provided by the 
original library.
 
I see benefit in libraries that extend Clojure’s datafy/nav to new domains as a 
narrow purpose that users can opt into. I see much less benefit in providing 
the same protocols and function names that core already includes, targeted to 
new types, in an isolated way such as this. Perhaps that is because I’m already 
using datafy/nav and I find their utility is enhanced by being extended to 
other Java types?
 
Yes, if multiple people write multiple libraries A, B, C that extend datafy/nav 
to java.time types and then other libraries X, Y, Z start pulling in those 
extenders, consumers of X, Y, Z can be in trouble.
 
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
 
From: dimitris
Sent: Thursday, January 30, 2020 9:58 AM
To: clojure@googlegroups.com
Subject: Re: Feedback on datafy/nav project
 
Well, the official Clojure guidelines are to NOT extend protocols, unless you 
own either the protocol of the type(s) [1].
In particular these lines:
If you are a library developer, you should not extend if you own neither the 
protocol nor the target.
You should take particular care when extending protocols included with Clojure 
itself.
 
Kind regards,
Dimitris
[1]: https://clojure.org/reference/protocols#_extend_via_metadata
 
On 30/01/2020 17:50, Sean Corfield wrote:
Is there a reason you’ve mirrored those protocols/implementations rather than 
just use Clojure’s built-in versions?
 
As it stands, your library wouldn’t work with other tooling that builds on 
Clojure’s datafy/nav (REBL, for example).
 
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
 
From: dimitris
Sent: Thursday, January 30, 2020 9:05 AM
To: Clojure
Subject: Feedback on datafy/nav project
 
Hi folks,
 
I'm looking for honest and constructive feedback on [1] - not so much 
about the actual implementation (even though these are welcome too), but 
rather about the general idea of basing everything on top of (mirrored 
versions) `datafy` and `nav` (in this way). There is a TL;DR section at 
t

Re: Feedback on datafy/nav project

[dimitris]

Ok, thanks a million Alex


On 31/01/2020 21:13, Alex Miller wrote:
Datafiable is not special, the guidelines (recently refreshed with 
Rich's input at 
https://clojure.org/reference/protocols#_guidelines_for_extension) 
still make sense, but are still just guidelines for your thinking not 
Laws whose breakage will land you in Clojure Jail.


If you want to make protocol extensions for java time objects to 
datafiable and put it in a lib, go for it. No one is making anyone 
else use it. Maybe some day we'll do that in core, maybe not.


I'm certain that copying Datafiable to your own version however would 
lead only to a) confusion and b) a certainty that no one else would 
actually use it, and that seems like a waste of time.



On Friday, January 31, 2020 at 1:24:09 PM UTC-6, Jim foo.bar wrote:

I tend to agree with you in where the benefit is - it's just that
the way the protocol docs are phrased, and some of the language
used in that mailing discussion from 10 years ago (from
authoritative sources like Rich and Stuart), implies that /no
library is to extend clojure.core protocols to core Java objects/,
and that only Clojure itself is allowed do that. The example
Stuart gave back then with the english/spelling-corrector VS
spanish/spelling-corrector is pretty telling...

Could it perhaps be the case that `Datafiable` is somewhat special
in that, it was conceived for the purpose of open extension by
third parties, and that the protocol extension guidelines don't
really apply to it (or perhaps not as strictly)?


Thanks for taking the time :)

Dimitris


On 31/01/2020 01:23, Sean Corfield wrote:


If your library is intended specifically to provide the ability
to datafy/nav java.time objects then it is something optional
that users can choose to opt into.

The section you meant to link to
https://clojure.org/reference/protocols#_guidelines_for_extension

says: “To minimize conflicts, consider these guidelines”

So they’re a) guidelines and b) just given as a caution to
minimize conflicts.

There are libraries out there already that exist specifically to
give users the option to extend protocols from one library (such
as clojure.java.jdbc or next.jdbc) to Java types to provide
customized behavior, above and beyond the “base versions for
common targets” mentioned in that section provided by the
original library.

I see benefit in libraries that extend Clojure’s datafy/nav to
new domains as a narrow purpose that users can opt into. I see
much less benefit in providing the same protocols and function
names that core already includes, targeted to new types, in an
isolated way such as this. Perhaps that is because I’m already
using datafy/nav and I find their utility is enhanced by being
extended to other Java types?

Yes, if multiple people write multiple libraries A, B, C that
extend datafy/nav to java.time types and then other libraries X,
Y, Z start pulling in those extenders, consumers of X, Y, Z can
be in trouble.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

*From: *dimitris 
*Sent: *Thursday, January 30, 2020 9:58 AM
*To: *clojure@googlegroups.com 
*Subject: *Re: Feedback on datafy/nav project

Well, the official Clojure guidelines are to NOT extend
protocols, unless you own either the protocol of the type(s) [1].

In particular these lines:

/If you are a library developer, you should not extend if you own
neither the protocol nor the target./

/You should take particular care when extending protocols
included with Clojure itself./

Kind regards,

Dimitris

[1]: https://clojure.org/reference/protocols#_extend_via_metadata


On 30/01/2020 17:50, Sean Corfield wrote:

Is there a reason you’ve mirrored those
protocols/implementations rather than just use Clojure’s
built-in versions?

As it stands, your library wouldn’t work with other tooling
that builds on Clojure’s datafy/nav (REBL, for example).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

*From: *dimitris 
*Sent: *Thursday, January 30, 2020 9:05 AM
*To: *Clojure 
*Subject: *Feedback on datafy/nav project

Hi folks,

I'm looking for honest and constructive feedback on [1] - not
so much

about the actual implem

Re: Recursively convert Java Map to Clojure Map

[Jason Ross]

Thanks for the reply. I do need to convert to java hashmaps and arraylists 
because I'm trying to duplicate the testing of a clojure workflow being run 
on a server thats pushing pure java context through it. So in my tests I 
define a clojure map but want to javafy it to force errors to happen when I 
try to evaluate the map as a function. 

It's not clear to my how the postwalk-replace will work for converting 
specific types (clojure maps and lists) to other types (java hashmaps and 
array lists) recursively. Is the extend-protocol method discussed below not 
the way to go?

On Friday, January 31, 2020 at 3:15:29 PM UTC-6, Alex Miller wrote:
>
> You don't need that - Clojure maps *are* Java maps (they implement 
> java.util.Map) and you can pass them into most Java APIs as is (with the 
> caveat that they are made for reading, not for writing).
>
> If you did really want to convert them to hash-maps or whatever, it's 
> pretty easy to do so with a clojure.walk/postwalk-replace.
>
> On Friday, January 31, 2020 at 3:07:24 PM UTC-6, Jason Ross wrote:
>>
>> Hey I know this is super old post but what would the reverse look like, 
>> eg. recursively convert Clojure to java map
>>
>> On Saturday, October 15, 2011 at 4:10:32 AM UTC-5, Baishampayan Ghose 
>> wrote:
>>>
>>> > I have a Java Map contains Map of Maps/List (JSON like map) and have
>>> > to convert to Clojure map (This happens at Java - Clojure Interop), So
>>> > I have written a converter function 'as-clj-map' by modifying the
>>> > clojure walk functions, It works fine, but consume lot of cpu when the
>>> > data structure is quit big. Any suggestions to improve this code?
>>>
>>> What about using protocols for this job?
>>>
>>> (defprotocol ConvertibleToClojure
>>>   (->clj [o]))
>>>
>>> (extend-protocol ConvertibleToClojure
>>>   java.util.Map
>>>   (->clj [o] (let [entries (.entrySet o)]
>>>(reduce (fn [m [^String k v]]
>>>  (assoc m (keyword k) (->clj v)))
>>>{} entries)))
>>>
>>>   java.util.List
>>>   (->clj [o] (vec (map ->clj o)))
>>>
>>>   java.lang.Object
>>>   (->clj [o] o)
>>>
>>>   nil
>>>   (->clj [_] nil))
>>>
>>> (defn as-clj-map
>>>   [m]
>>>   (->clj m))
>>>
>>>
>>> Let me know if this works for you & meets your performance requirements.
>>>
>>> Regards,
>>> BG
>>>
>>> -- 
>>> Baishampayan Ghose
>>> b.ghose at gmail.com
>>>
>>>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/a4762b64-5131-4b8f-b794-da3ce41a0c86%40googlegroups.com.

Re: Recursively convert Java Map to Clojure Map

[Alex Miller]

You don't need that - Clojure maps *are* Java maps (they implement 
java.util.Map) and you can pass them into most Java APIs as is (with the 
caveat that they are made for reading, not for writing).

If you did really want to convert them to hash-maps or whatever, it's 
pretty easy to do so with a clojure.walk/postwalk-replace.

On Friday, January 31, 2020 at 3:07:24 PM UTC-6, Jason Ross wrote:
>
> Hey I know this is super old post but what would the reverse look like, 
> eg. recursively convert Clojure to java map
>
> On Saturday, October 15, 2011 at 4:10:32 AM UTC-5, Baishampayan Ghose 
> wrote:
>>
>> > I have a Java Map contains Map of Maps/List (JSON like map) and have
>> > to convert to Clojure map (This happens at Java - Clojure Interop), So
>> > I have written a converter function 'as-clj-map' by modifying the
>> > clojure walk functions, It works fine, but consume lot of cpu when the
>> > data structure is quit big. Any suggestions to improve this code?
>>
>> What about using protocols for this job?
>>
>> (defprotocol ConvertibleToClojure
>>   (->clj [o]))
>>
>> (extend-protocol ConvertibleToClojure
>>   java.util.Map
>>   (->clj [o] (let [entries (.entrySet o)]
>>(reduce (fn [m [^String k v]]
>>  (assoc m (keyword k) (->clj v)))
>>{} entries)))
>>
>>   java.util.List
>>   (->clj [o] (vec (map ->clj o)))
>>
>>   java.lang.Object
>>   (->clj [o] o)
>>
>>   nil
>>   (->clj [_] nil))
>>
>> (defn as-clj-map
>>   [m]
>>   (->clj m))
>>
>>
>> Let me know if this works for you & meets your performance requirements.
>>
>> Regards,
>> BG
>>
>> -- 
>> Baishampayan Ghose
>> b.ghose at gmail.com
>>
>>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/cfe49f86-1995-4098-ae89-208a46d2fc76%40googlegroups.com.

Re: Feedback on datafy/nav project

[Alex Miller]

Datafiable is not special, the guidelines (recently refreshed with Rich's 
input at https://clojure.org/reference/protocols#_guidelines_for_extension) 
still make sense, but are still just guidelines for your thinking not Laws 
whose breakage will land you in Clojure Jail.

If you want to make protocol extensions for java time objects to datafiable 
and put it in a lib, go for it. No one is making anyone else use it. Maybe 
some day we'll do that in core, maybe not.

I'm certain that copying Datafiable to your own version however would lead 
only to a) confusion and b) a certainty that no one else would actually use 
it, and that seems like a waste of time.


On Friday, January 31, 2020 at 1:24:09 PM UTC-6, Jim foo.bar wrote:
>
> I tend to agree with you in where the benefit is - it's just that the way 
> the protocol docs are phrased, and some of the language used in that 
> mailing discussion from 10 years ago (from authoritative sources like Rich 
> and Stuart), implies that *no library is to extend clojure.core protocols 
> to core Java objects*, and that only Clojure itself is allowed do that. 
> The example Stuart gave back then with the english/spelling-corrector VS 
> spanish/spelling-corrector is pretty telling...
>
> Could it perhaps be the case that `Datafiable` is somewhat special in 
> that, it was conceived for the purpose of open extension by third parties, 
> and that the protocol extension guidelines don't really apply to it (or 
> perhaps not as strictly)?  
>
>
> Thanks for taking the time :)
>
> Dimitris
>
>
> On 31/01/2020 01:23, Sean Corfield wrote:
>
> If your library is intended specifically to provide the ability to 
> datafy/nav java.time objects then it is something optional that users can 
> choose to opt into.
>
>  
>
> The section you meant to link to 
> https://clojure.org/reference/protocols#_guidelines_for_extension says: “To 
> minimize conflicts, consider these guidelines”
>
>  
>
> So they’re a) guidelines and b) just given as a caution to minimize 
> conflicts.
>
>  
>
> There are libraries out there already that exist specifically to give 
> users the option to extend protocols from one library (such as 
> clojure.java.jdbc or next.jdbc) to Java types to provide customized 
> behavior, above and beyond the “base versions for common targets” 
> mentioned in that section provided by the original library.
>
>  
>
> I see benefit in libraries that extend Clojure’s datafy/nav to new domains 
> as a narrow purpose that users can opt into. I see much less benefit in 
> providing the same protocols and function names that core already includes, 
> targeted to new types, in an isolated way such as this. Perhaps that is 
> because I’m already using datafy/nav and I find their utility is enhanced 
> by being extended to other Java types?
>
>  
>
> Yes, if multiple people write multiple libraries A, B, C that extend 
> datafy/nav to java.time types and then other libraries X, Y, Z start 
> pulling in those extenders, consumers of X, Y, Z can be in trouble.
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *dimitris 
> *Sent: *Thursday, January 30, 2020 9:58 AM
> *To: *clojure@googlegroups.com
> *Subject: *Re: Feedback on datafy/nav project
>
>  
>
> Well, the official Clojure guidelines are to NOT extend protocols, unless 
> you own either the protocol of the type(s) [1].
>
> In particular these lines:
>
> *If you are a library developer, you should not extend if you own neither 
> the protocol nor the target.*
>
> *You should take particular care when extending protocols included with 
> Clojure itself.*
>
>  
>
> Kind regards,
>
> Dimitris
>
> [1]: https://clojure.org/reference/protocols#_extend_via_metadata
>
>  
>
> On 30/01/2020 17:50, Sean Corfield wrote:
>
> Is there a reason you’ve mirrored those protocols/implementations rather 
> than just use Clojure’s built-in versions?
>
>  
>
> As it stands, your library wouldn’t work with other tooling that builds on 
> Clojure’s datafy/nav (REBL, for example).
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *dimitris 
> *Sent: *Thursday, January 30, 2020 9:05 AM
> *To: *Clojure 
> *Subject: *Feedback on datafy/nav project
>
>  
>
> Hi folks,
>
>  
>
> I'm looking for honest and constructive feedback on [1] - not so much 
>
> about the actual implementation (even though these are welcome too), but 
>
> rather about the general idea of basing everything on top of (mirrored 
>
> versions) `datafy` and `nav` (in this way). There is a TL;DR section at 
>
> the very bottom that describes the approach in 4 short sentences.
>
>  
>
> Many thanks in advance,
>
>  
>
> Dimitris
>
>  
>
> [1]: https://github.com/jimpil/jedi-time
>
>  
>
>  
>
> -- 
>
> You received 

Re: Recursively convert Java Map to Clojure Map

[Jason Ross]

Hey I know this is super old post but what would the reverse look like, eg. 
recursively convert Clojure to java map

On Saturday, October 15, 2011 at 4:10:32 AM UTC-5, Baishampayan Ghose wrote:
>
> > I have a Java Map contains Map of Maps/List (JSON like map) and have
> > to convert to Clojure map (This happens at Java - Clojure Interop), So
> > I have written a converter function 'as-clj-map' by modifying the
> > clojure walk functions, It works fine, but consume lot of cpu when the
> > data structure is quit big. Any suggestions to improve this code?
>
> What about using protocols for this job?
>
> (defprotocol ConvertibleToClojure
>   (->clj [o]))
>
> (extend-protocol ConvertibleToClojure
>   java.util.Map
>   (->clj [o] (let [entries (.entrySet o)]
>(reduce (fn [m [^String k v]]
>  (assoc m (keyword k) (->clj v)))
>{} entries)))
>
>   java.util.List
>   (->clj [o] (vec (map ->clj o)))
>
>   java.lang.Object
>   (->clj [o] o)
>
>   nil
>   (->clj [_] nil))
>
> (defn as-clj-map
>   [m]
>   (->clj m))
>
>
> Let me know if this works for you & meets your performance requirements.
>
> Regards,
> BG
>
> -- 
> Baishampayan Ghose
> b.ghose at gmail.com
>
>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/30c8edaf-bafe-4e78-9503-430d9f2c85ef%40googlegroups.com.

Re: Feedback on datafy/nav project

[dimitris]

I tend to agree with you in where the benefit is - it's just that the 
way the protocol docs are phrased, and some of the language used in that 
mailing discussion from 10 years ago (from authoritative sources like 
Rich and Stuart), implies that /no library is to extend clojure.core 
protocols to core Java objects/, and that only Clojure itself is allowed 
do that. The example Stuart gave back then with the 
english/spelling-corrector VS spanish/spelling-corrector is pretty 
telling...


Could it perhaps be the case that `Datafiable` is somewhat special in 
that, it was conceived for the purpose of open extension by third 
parties, and that the protocol extension guidelines don't really apply 
to it (or perhaps not as strictly)?



Thanks for taking the time :)

Dimitris


On 31/01/2020 01:23, Sean Corfield wrote:


If your library is intended specifically to provide the ability to 
datafy/nav java.time objects then it is something optional that users 
can choose to opt into.


The section you meant to link to 
https://clojure.org/reference/protocols#_guidelines_for_extension 
says: “To minimize conflicts, consider these guidelines”


So they’re a) guidelines and b) just given as a caution to minimize 
conflicts.


There are libraries out there already that exist specifically to give 
users the option to extend protocols from one library (such as 
clojure.java.jdbc or next.jdbc) to Java types to provide customized 
behavior, above and beyond the “base versions for common targets” 
mentioned in that section provided by the original library.


I see benefit in libraries that extend Clojure’s datafy/nav to new 
domains as a narrow purpose that users can opt into. I see much less 
benefit in providing the same protocols and function names that core 
already includes, targeted to new types, in an isolated way such as 
this. Perhaps that is because I’m already using datafy/nav and I find 
their utility is enhanced by being extended to other Java types?


Yes, if multiple people write multiple libraries A, B, C that extend 
datafy/nav to java.time types and then other libraries X, Y, Z start 
pulling in those extenders, consumers of X, Y, Z can be in trouble.


Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

*From: *dimitris 
*Sent: *Thursday, January 30, 2020 9:58 AM
*To: *clojure@googlegroups.com 
*Subject: *Re: Feedback on datafy/nav project

Well, the official Clojure guidelines are to NOT extend protocols, 
unless you own either the protocol of the type(s) [1].


In particular these lines:

/If you are a library developer, you should not extend if you own 
neither the protocol nor the target./


/You should take particular care when extending protocols included 
with Clojure itself./


Kind regards,

Dimitris

[1]: https://clojure.org/reference/protocols#_extend_via_metadata

On 30/01/2020 17:50, Sean Corfield wrote:

Is there a reason you’ve mirrored those protocols/implementations
rather than just use Clojure’s built-in versions?

As it stands, your library wouldn’t work with other tooling that
builds on Clojure’s datafy/nav (REBL, for example).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

*From: *dimitris 
*Sent: *Thursday, January 30, 2020 9:05 AM
*To: *Clojure 
*Subject: *Feedback on datafy/nav project

Hi folks,

I'm looking for honest and constructive feedback on [1] - not so much

about the actual implementation (even though these are welcome
too), but

rather about the general idea of basing everything on top of
(mirrored

versions) `datafy` and `nav` (in this way). There is a TL;DR
section at

the very bottom that describes the approach in 4 short sentences.

Many thanks in advance,

Dimitris

[1]: https://github.com/jimpil/jedi-time

-- 


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, send email to

clojure+unsubscr...@googlegroups.com


For more options, visit this group at

http://groups.google.com/group/clojure?hl=en

---

You received this message because you are subscribed to the Google
Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.

To