Dynamically Reify Interfaces

[Nick Mudge]

I need to dynamically reify some java interfaces based on data from a map.  
One way I can see to do this is to generate the reify code with a function 
using syntax quotes, quotes and unquote and unquote splice.  And then 
evaluate it using eval. I hesitate using eval, but is eval the right tool 
for this case?  

Normally I would write a macro to generate code. A macro is good for 
generating code from source code. But in this case the data that is used to 
generate the code is coming from a var that holds a data structure.

Any thoughts about when it is okay/good to use eval in Clojure?



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Didier]

I found private/public works fine. I put my public interface at the bottom 
of the file with a nice comment header. Using another namespace like .impl, 
I've always had the issue that nobody on my team can agree with what the 
name convention should be for what an impl namespace should be called , 
so private has had less controversy. It can lead to pretty large file, and 
splitting namespaces across more then one file, even though supported, 
messes up with a lot of tooling, so I also avoid that.

I think, what I've struggled with is how to move an API to another 
namespace, while maintaining backwards compatibility. This happens a lot 
where I work, where we want to refactor the namespace structure, and move 
things around, and rename namespaces, but we're not sure if there were 
other packages that depend on it which would break. So I'd want to take the 
existing namespace, and move all its vars in a new namespace, but where the 
old namespace still exists as a frozen immutable interface that now maps 
back to the new. Yet I've hesitated to use potemkin, because its non ideal. 
I'm still hoping here for a better solution to this to show up.

On Tuesday, 7 November 2017 13:42:16 UTC-8, Sean Corfield wrote:
>
> I’m with Timothy (and Alex) on Potemkin. For me, it’s been the source of 
> some very weird transitive dependency bugs as well as strange binding 
> issues across a number of projects where it has been dragged in by various 
> third party libraries (e.g., clj-http). It’s made me very wary of it 
>
>  
>
> I have – very occasionally – used (home-grown) functionality to “import” 
> vars from one namespace to another, but without the watchers or any other 
> “magic”, and it’s been done only when the convenience of a loop to intern 
> symbols dramatically outweighs the effort of writing the delegation 
> functions by hand (expectations.clojure.test currently does that to expose 
> much of the old expectations API as-is while I’m transitioning how the 
> library works). I consider it very much an interim/transition solution, 
> that should be avoided in normal production code.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Timothy Baldridge  >
> *Sent:* Tuesday, November 7, 2017 11:11:14 AM
> *To:* clo...@googlegroups.com 
> *Subject:* Re: Who Uses import-vars? 
>  
> I structure my code very explicitly. Normally the most common constructs 
> are put in a single file named after the library itself (not in core.clj, 
> do that half your files will be named core). 
>
> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj
>
> Anything not in the API that should be unpublished to users is in other 
> namespaces that are imported and wrapped by vars in the main namespace. 
> This does several things:
>
> * Keeps the public interface in one place
> * Allows for a different public interface than the private one. Notice how 
> Odin has its own version of `when`, pulling that off require a bit of 
> careful macro usage, so I'd rather write that once under a different name, 
> then rename it to `when`. 
> * It's now simple to say "anything in this namespace is public and will 
> not change"
>
> Core.async uses a pattern much like this, the API is in 
> clojure.core.async, most of the logic is under *.async.impl.*. 
>
> I don't recommend potemkin's import-vars at all. Clojure vars were not 
> meant to exist in more than one namespace at a time, so potemkin pulls of 
> its magic by linking two vars via watchers. This means that changes to one 
> var can cause side-effects in the other. In addition, bindings don't convey 
> properly (AFAIK), so if you using bindings on one var, the changes won't be 
> seen in the other var. Remember: import-vars doesn't actually import 
> anything, it simply creates a new var in the current namespace and links 
> the two via a two-way binding. It's quite the hack, imo. 
>
> So I have to agree with Potemkin's tagline on github: it's an idea that's 
> "almost good". 
>
> Timothy
>
> On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge  > wrote:
>
>> I am interested to know if people/you use import-vars to decouple the 
>> structure of code from its API. 
>>
>> import-vars is from the potemkin library: 
>> https://github.com/ztellman/potemkin
>>
>> If you don't use import-vars how do you structure your code and provide 
>> an API?
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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
>> 

ANN: Kibit 0.1.6

[Daniel Compton]

Hi folks

Kibit 0.1.6  is out now.

There are a few fixes you can see in the release notes, but the big one by
far is that Kibit now supports reading namespaced keywords correctly, just
in time for Clojure 1.9. This has been an open issue
 since 2012(!). A massive thanks
to Alex Redinger who put together the PR
 for this, and to Reid McKenzie
who is sharing the maintainership duties with me.

You can find the new release at your friendly neighbourhood Clojars
.

Happy kibiting, and let me know here or in the GitHub issues if you have
any issues.

--
Daniel.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

RE: Who Uses import-vars?

[Sean Corfield]

I’m with Timothy (and Alex) on Potemkin. For me, it’s been the source of some 
very weird transitive dependency bugs as well as strange binding issues across 
a number of projects where it has been dragged in by various third party 
libraries (e.g., clj-http). It’s made me very wary of it 

I have – very occasionally – used (home-grown) functionality to “import” vars 
from one namespace to another, but without the watchers or any other “magic”, 
and it’s been done only when the convenience of a loop to intern symbols 
dramatically outweighs the effort of writing the delegation functions by hand 
(expectations.clojure.test currently does that to expose much of the old 
expectations API as-is while I’m transitioning how the library works). I 
consider it very much an interim/transition solution, that should be avoided in 
normal production code.

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

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


From: clojure@googlegroups.com  on behalf of Timothy 
Baldridge 
Sent: Tuesday, November 7, 2017 11:11:14 AM
To: clojure@googlegroups.com
Subject: Re: Who Uses import-vars?

I structure my code very explicitly. Normally the most common constructs are 
put in a single file named after the library itself (not in core.clj, do that 
half your files will be named core).

https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj

Anything not in the API that should be unpublished to users is in other 
namespaces that are imported and wrapped by vars in the main namespace. This 
does several things:

* Keeps the public interface in one place
* Allows for a different public interface than the private one. Notice how Odin 
has its own version of `when`, pulling that off require a bit of careful macro 
usage, so I'd rather write that once under a different name, then rename it to 
`when`.
* It's now simple to say "anything in this namespace is public and will not 
change"

Core.async uses a pattern much like this, the API is in clojure.core.async, 
most of the logic is under *.async.impl.*.

I don't recommend potemkin's import-vars at all. Clojure vars were not meant to 
exist in more than one namespace at a time, so potemkin pulls of its magic by 
linking two vars via watchers. This means that changes to one var can cause 
side-effects in the other. In addition, bindings don't convey properly (AFAIK), 
so if you using bindings on one var, the changes won't be seen in the other 
var. Remember: import-vars doesn't actually import anything, it simply creates 
a new var in the current namespace and links the two via a two-way binding. 
It's quite the hack, imo.

So I have to agree with Potemkin's tagline on github: it's an idea that's 
"almost good".

Timothy

On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge 
> wrote:
I am interested to know if people/you use import-vars to decouple the structure 
of code from its API.

import-vars is from the potemkin library: https://github.com/ztellman/potemkin

If you don't use import-vars how do you structure your code and provide an API?



--
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.
For more options, visit https://groups.google.com/d/optout.



--
“One of the main causes of the fall of the Roman Empire was that–lacking 
zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

--
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.
For more options, visit 

Re: Migrating nREPL out of Clojure Contrib

[Nick Mudge]

I am new to the clojure community. What does it mean to "reboot" the 
project?


On Friday, July 21, 2017 at 5:15:49 AM UTC-7, Herwig Hochleitner wrote:
>
> 2017-07-18 14:48 GMT+02:00 Chas Emerick  >:
> > I would like to hear here (no more private mails, please! :-) from any 
> nREPL users, contributors, etc. As much as possible, I would like not to 
> debate/re-litigate the merits of contrib and its process here; let's focus 
> on what steps will yield the best outcome for nREPL and its stakeholders.
>
> I only have a stake as a user (unfortunately), but FWIW, I'd much rather 
> see nREPL stay within contrib and the renewed effort, that you propose, to 
> go into ironing out kinks in the contrib process (e.g. for one-off 
> contributions, the assignment could go into the commit message, maybe?; 
> also our atlassian versions could do with an update; also, it would be 
> _really_ nice, if patches could be discussed/accepted on the [dev-] mailing 
> list, LKML style)
>
> I realize, that this is effectively asking Chas to roll the boulder up the 
> hill, yet another time, but my reason is simple:
> For infrastructure, free market principles don't easily apply: People 
> generally fix roads instead of adding new ones in parallel to existing 
> ones, and if there ever is an "infrastructurey" clojure library, it would 
> be tools.nrepl. Also, like Sean Corfield, I have my reservations about the 
> potential for contribution increases due to a reboot.
> To me the risks of a reboot far outweigh the potential benefits.
>
> That said, Chas and Bozhidar, as the largest stakeholders, both seem to be 
> in favor of a reboot, hence I wouldn't veto it even if I could.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Alex Miller]

I agree with Tim - I don't like any of the Potemkin import-* functionality. 
Every time I am working against libs like this, "go to source" ends up in 
the wrong place. From my perspective, this is a bit of complexity and 
redirection that serves little purpose other than to confuse those looking 
at the implementation. Using public/private vars and implementation 
namespaces is sufficient to cover every case I've found useful.

On Tuesday, November 7, 2017 at 1:11:30 PM UTC-6, tbc++ wrote:
>
> I structure my code very explicitly. Normally the most common constructs 
> are put in a single file named after the library itself (not in core.clj, 
> do that half your files will be named core). 
>
> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj 
> 
>
> Anything not in the API that should be unpublished to users is in other 
> namespaces that are imported and wrapped by vars in the main namespace. 
> This does several things:
>
> * Keeps the public interface in one place
> * Allows for a different public interface than the private one. Notice how 
> Odin has its own version of `when`, pulling that off require a bit of 
> careful macro usage, so I'd rather write that once under a different name, 
> then rename it to `when`. 
> * It's now simple to say "anything in this namespace is public and will 
> not change"
>
> Core.async uses a pattern much like this, the API is in 
> clojure.core.async, most of the logic is under *.async.impl.*. 
>
> I don't recommend potemkin's import-vars at all. Clojure vars were not 
> meant to exist in more than one namespace at a time, so potemkin pulls of 
> its magic by linking two vars via watchers. This means that changes to one 
> var can cause side-effects in the other. In addition, bindings don't convey 
> properly (AFAIK), so if you using bindings on one var, the changes won't be 
> seen in the other var. Remember: import-vars doesn't actually import 
> anything, it simply creates a new var in the current namespace and links 
> the two via a two-way binding. It's quite the hack, imo. 
>
> So I have to agree with Potemkin's tagline on github: it's an idea that's 
> "almost good". 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Alan Thompson]

Looking at the source code here

I
can see that `import-vars` delegates to `import-fn` or `import-macro`,
which in turn calls `link-vars`. That uses `add-watch` with a function
described by the docstring:  "Makes sure that all changes to `src` are
reflected in `dst`."

​I haven't seen any problems in using it for a year or so, but the
implementation is not the same as I expected.  Hmmm.

Alan​


On Tue, Nov 7, 2017 at 12:08 PM, Alan Thompson  wrote:

> In the Tupelo library, I have been using `import-fn` and `import-macro`
> from Potemkin so that I can define functions/macros in a single namespace
> `tupelo.impl`, but then expose an API in "user-visible" namespaces like:
>
>- tupelo.core
>- tupelo.char
>- tupelo.test
>- etc
>
> Perhaps I've been doing it wrong and should switch to `import-vars`.?
> Alan
>
>
> On Tue, Nov 7, 2017 at 10:13 AM, Nick Mudge 
> wrote:
>
>> I am interested to know if people/you use import-vars to decouple the
>> structure of code from its API.
>>
>> import-vars is from the potemkin library: https://github.com/ztellman/po
>> temkin
>>
>> If you don't use import-vars how do you structure your code and provide
>> an API?
>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Nick Mudge]

I think import-vars is for convenience. It delegates to import-fn and 
import-macro. 

On Tuesday, November 7, 2017 at 12:09:10 PM UTC-8, Alan Thompson wrote:
>
> In the Tupelo library, I have been using `import-fn` and `import-macro` 
> from Potemkin so that I can define functions/macros in a single namespace 
> `tupelo.impl`, but then expose an API in "user-visible" namespaces like:
>
>- tupelo.core
>- tupelo.char
>- tupelo.test
>- etc
>
> Perhaps I've been doing it wrong and should switch to `import-vars`.?
> Alan
>
>
> On Tue, Nov 7, 2017 at 10:13 AM, Nick Mudge  > wrote:
>
>> I am interested to know if people/you use import-vars to decouple the 
>> structure of code from its API.
>>
>> import-vars is from the potemkin library: 
>> https://github.com/ztellman/potemkin
>>
>> If you don't use import-vars how do you structure your code and provide 
>> an API?
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Nick Mudge]

Thanks Timothy, this is really useful!

On Tuesday, November 7, 2017 at 11:11:30 AM UTC-8, tbc++ wrote:
>
> I structure my code very explicitly. Normally the most common constructs 
> are put in a single file named after the library itself (not in core.clj, 
> do that half your files will be named core). 
>
> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj
>
> Anything not in the API that should be unpublished to users is in other 
> namespaces that are imported and wrapped by vars in the main namespace. 
> This does several things:
>
> * Keeps the public interface in one place
> * Allows for a different public interface than the private one. Notice how 
> Odin has its own version of `when`, pulling that off require a bit of 
> careful macro usage, so I'd rather write that once under a different name, 
> then rename it to `when`. 
> * It's now simple to say "anything in this namespace is public and will 
> not change"
>
> Core.async uses a pattern much like this, the API is in 
> clojure.core.async, most of the logic is under *.async.impl.*. 
>
> I don't recommend potemkin's import-vars at all. Clojure vars were not 
> meant to exist in more than one namespace at a time, so potemkin pulls of 
> its magic by linking two vars via watchers. This means that changes to one 
> var can cause side-effects in the other. In addition, bindings don't convey 
> properly (AFAIK), so if you using bindings on one var, the changes won't be 
> seen in the other var. Remember: import-vars doesn't actually import 
> anything, it simply creates a new var in the current namespace and links 
> the two via a two-way binding. It's quite the hack, imo. 
>
> So I have to agree with Potemkin's tagline on github: it's an idea that's 
> "almost good". 
>
> Timothy
>
> On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge  > wrote:
>
>> I am interested to know if people/you use import-vars to decouple the 
>> structure of code from its API.
>>
>> import-vars is from the potemkin library: 
>> https://github.com/ztellman/potemkin
>>
>> If you don't use import-vars how do you structure your code and provide 
>> an API?
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Alan Thompson]

In the Tupelo library, I have been using `import-fn` and `import-macro`
from Potemkin so that I can define functions/macros in a single namespace
`tupelo.impl`, but then expose an API in "user-visible" namespaces like:

   - tupelo.core
   - tupelo.char
   - tupelo.test
   - etc

Perhaps I've been doing it wrong and should switch to `import-vars`.?
Alan


On Tue, Nov 7, 2017 at 10:13 AM, Nick Mudge 
wrote:

> I am interested to know if people/you use import-vars to decouple the
> structure of code from its API.
>
> import-vars is from the potemkin library: https://github.com/ztellman/
> potemkin
>
> If you don't use import-vars how do you structure your code and provide an
> API?
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Nick Mudge]

Thanks Ducan, this is incredibly useful!

On Tuesday, November 7, 2017 at 11:17:28 AM UTC-8, Duncan McGreggor wrote:
>
>
>
> On 7 November 2017 at 13:11, Timothy Baldridge  > wrote:
>
>> I structure my code very explicitly. Normally the most common constructs 
>> are put in a single file named after the library itself (not in core.clj, 
>> do that half your files will be named core). 
>>
>> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj
>>
>> Anything not in the API that should be unpublished to users is in other 
>> namespaces that are imported and wrapped by vars in the main namespace. 
>> This does several things:
>>
>> * Keeps the public interface in one place
>> * Allows for a different public interface than the private one. Notice 
>> how Odin has its own version of `when`, pulling that off require a bit of 
>> careful macro usage, so I'd rather write that once under a different name, 
>> then rename it to `when`. 
>> * It's now simple to say "anything in this namespace is public and will 
>> not change"
>>
>> Core.async uses a pattern much like this, the API is in 
>> clojure.core.async, most of the logic is under *.async.impl.*. 
>>
>
> This is a great practice; it's how I do all my protocols/implementations 
> now.
>  
>
>> I don't recommend potemkin's import-vars at all. Clojure vars were not 
>> meant to exist in more than one namespace at a time, so potemkin pulls of 
>> its magic by linking two vars via watchers. This means that changes to one 
>> var can cause side-effects in the other. In addition, bindings don't convey 
>> properly (AFAIK), so if you using bindings on one var, the changes won't be 
>> seen in the other var. Remember: import-vars doesn't actually import 
>> anything, it simply creates a new var in the current namespace and links 
>> the two via a two-way binding. It's quite the hack, imo. 
>>
>
> Huh. Good to know. Will have to ponder ...
>
> d
>
>
>> So I have to agree with Potemkin's tagline on github: it's an idea that's 
>> "almost good". 
>>
>> Timothy
>>
>> On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge <
>> ni...@perfectabstractions.com > wrote:
>>
>>> I am interested to know if people/you use import-vars to decouple the 
>>> structure of code from its API.
>>>
>>> import-vars is from the potemkin library: 
>>> https://github.com/ztellman/potemkin
>>>
>>> If you don't use import-vars how do you structure your code and provide 
>>> an API?
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.”
>> (Robert Firth) 
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Duncan McGreggor]

On 7 November 2017 at 13:11, Timothy Baldridge  wrote:

> I structure my code very explicitly. Normally the most common constructs
> are put in a single file named after the library itself (not in core.clj,
> do that half your files will be named core).
>
> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj
>
> Anything not in the API that should be unpublished to users is in other
> namespaces that are imported and wrapped by vars in the main namespace.
> This does several things:
>
> * Keeps the public interface in one place
> * Allows for a different public interface than the private one. Notice how
> Odin has its own version of `when`, pulling that off require a bit of
> careful macro usage, so I'd rather write that once under a different name,
> then rename it to `when`.
> * It's now simple to say "anything in this namespace is public and will
> not change"
>
> Core.async uses a pattern much like this, the API is in
> clojure.core.async, most of the logic is under *.async.impl.*.
>

This is a great practice; it's how I do all my protocols/implementations
now.


> I don't recommend potemkin's import-vars at all. Clojure vars were not
> meant to exist in more than one namespace at a time, so potemkin pulls of
> its magic by linking two vars via watchers. This means that changes to one
> var can cause side-effects in the other. In addition, bindings don't convey
> properly (AFAIK), so if you using bindings on one var, the changes won't be
> seen in the other var. Remember: import-vars doesn't actually import
> anything, it simply creates a new var in the current namespace and links
> the two via a two-way binding. It's quite the hack, imo.
>

Huh. Good to know. Will have to ponder ...

d


> So I have to agree with Potemkin's tagline on github: it's an idea that's
> "almost good".
>
> Timothy
>
> On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge 
> wrote:
>
>> I am interested to know if people/you use import-vars to decouple the
>> structure of code from its API.
>>
>> import-vars is from the potemkin library: https://github.com/ztellman/po
>> temkin
>>
>> If you don't use import-vars how do you structure your code and provide
>> an API?
>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Timothy Baldridge]

I structure my code very explicitly. Normally the most common constructs
are put in a single file named after the library itself (not in core.clj,
do that half your files will be named core).

https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj

Anything not in the API that should be unpublished to users is in other
namespaces that are imported and wrapped by vars in the main namespace.
This does several things:

* Keeps the public interface in one place
* Allows for a different public interface than the private one. Notice how
Odin has its own version of `when`, pulling that off require a bit of
careful macro usage, so I'd rather write that once under a different name,
then rename it to `when`.
* It's now simple to say "anything in this namespace is public and will not
change"

Core.async uses a pattern much like this, the API is in clojure.core.async,
most of the logic is under *.async.impl.*.

I don't recommend potemkin's import-vars at all. Clojure vars were not
meant to exist in more than one namespace at a time, so potemkin pulls of
its magic by linking two vars via watchers. This means that changes to one
var can cause side-effects in the other. In addition, bindings don't convey
properly (AFAIK), so if you using bindings on one var, the changes won't be
seen in the other var. Remember: import-vars doesn't actually import
anything, it simply creates a new var in the current namespace and links
the two via a two-way binding. It's quite the hack, imo.

So I have to agree with Potemkin's tagline on github: it's an idea that's
"almost good".

Timothy

On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge 
wrote:

> I am interested to know if people/you use import-vars to decouple the
> structure of code from its API.
>
> import-vars is from the potemkin library: https://github.com/ztellman/
> potemkin
>
> If you don't use import-vars how do you structure your code and provide an
> API?
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Who Uses import-vars?

[Duncan McGreggor]

I use it in some large fraction of my Clojure projects (25-50%?). The
primary driver is to balance an "internal" organization (e.g., that allows
me to keep file line counts low) that would be cumbersome as an API vs. an
ideal "developer experience" (e.g., less hierarchy and easier access to
functions).

I've also used it more recently in a large, legacy project (7+ years) to
support old users of a non-versioned API while reorganizing the codebase to
be more consistent (i.e., harmonizing a half-decade's worth of changes).
potemkin made the end result very clean with no breaking changes and really
opened up the future for the project.

d


On 7 November 2017 at 12:13, Nick Mudge 
wrote:

> I am interested to know if people/you use import-vars to decouple the
> structure of code from its API.
>
> import-vars is from the potemkin library: https://github.com/ztellman/
> potemkin
>
> If you don't use import-vars how do you structure your code and provide an
> API?
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Who Uses import-vars?

[Nick Mudge]

I am interested to know if people/you use import-vars to decouple the 
structure of code from its API.

import-vars is from the potemkin library: 
https://github.com/ztellman/potemkin

If you don't use import-vars how do you structure your code and provide an 
API?


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[ANN] Clojure 1.9.0-RC1

[Alex Miller]

Clojure 1.9.0-RC1 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC1
- Leiningen: [org.clojure/clojure "1.9.0-RC1"]

1.9.0-RC1 is the same as 1.9.0-beta4.

We would appreciate anything you can do to try out this release. We do not 
plan to make any further changes prior to 1.9.0 release unless regressions 
are found.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Functional Programming Blogs

[Alex Mesropians]

Hey All,

Hope everyone is well! 

Just wanted to share with you Functional Works 

 which 
has curated various FP related articles from across the globe! Of course 
feel free to contribute if you have a blog you want to share : ) ! 

Check it out! 

thanks, 
Alex 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Migrating nREPL out of Clojure Contrib

[Chas Emerick]

A final update:

https://github.com/cemerick/nREPL has been reconstituted as described
previously, and a release candidate has been deployed to maven central
with contents effectively identical to the latest tools.nrepl release
(only difference is an ipv6-related bugfix that was encountered in the
process of setting up travis ci).

This is all to say that things are underway! I'll stop posting updates
here, so if you're interested, you can continue to track
https://github.com/cemerick/nREPL/issues/1 for the final first release,
and the issue tracker on github is also now populated with things from
JIRA that will get burned down prior to a 1.0.0 release.

All the best,

- Chas

On 10/9/2017 14:59, Chas Emerick wrote:
> I have opened two issues on the original nREPL repo:
>
> 1. Describing the background and rationale for the work to be done:
> https://github.com/cemerick/nREPL/issues/1
>
> 2. Enumerating the nREPL contributors to obtain explicit permission for
> their commits to be distributed under the terms of EPL only (i.e. absent
> the terms of the CA that governed their contribution to the tools.nrepl
> project): https://github.com/cemerick/nREPL/issues/2
>
> Once #2 is complete, then the list of tasks in #1 will be burned down.
> We'll then have a 100% compatible nREPL release out the door with
> different maven coordinates, etc., and those that are interested in
> contributing will be able to do so straightforwardly.
>
> Cheers,
>
> - Chas
>
> On 8/3/2017 00:36, Bozhidar Batsov wrote:
>> So, what's the next step here?
>


-- 
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.
For more options, visit https://groups.google.com/d/optout.