I much more prefer putting implementation details into separate namespaces.
>From there it's simple to mark them as :no-doc in some documentation tools
so that the vars don't get published. That way I can still test all my
code, and yet I can commit to only those namespaces that have published
APIs.
Or even just putting implementation details behind foo.bar.impl.* So that
it's clear that the contents of these namespaces should not be relied on.
This is what core.async does, and what a lot of my personal projects do.
Timothy
On Mon, Feb 26, 2018 at 8:47 PM, Didier <didi...@gmail.com> wrote:
> I’d even be happy if the default was private for def
>>
>
> I actually prefer private everything by default. Its the public things you
> want to be reminded to think through carefully. And Var access is pretty
> straightforward, in case your using a lib and they forgot to make something
> public you really need, but its way too late to change a default like that.
>
> I think we have to ask ourselves what's the use cases where we use private
> on a Var?
>
> I can think of:
>
> - When on a function - Implementation details, don't depend on it, it
> could change at any time in breaking ways, ie, use at your own risk.
> - When on state - You should not read this data directly, its
> representation is possibly not easy to consume (another public facing
> mechanism exist to get a better representation of it), or you can't depend
> on the shape of this data not to change or this data even existing long
> term. Thus again, its implementation details.
> - When on state - You should not write to this data directly, it has
> strict invariants, and so if you do decide to write to it, be careful you
> understand and maintain them.
>
> Can anyone think of more use cases?
>
> I'm not even sure the concept of private and public make sense. Could
> there be a better construct to solve these use cases?
>
> I feel private would make sense in a security perspective, if there was no
> way to bypass it, for say running untrusted code within your code, but
> that's not what private does in any way.
>
> On Monday, 26 February 2018 17:41:15 UTC-8, Alex Miller wrote:
>>
>> We're not going to add def-. There is regret over even adding defn-, but
>> we don't take things away...
>>
>> At one point all of the current metadata niceties didn't exist (used to
>> be #^{:private true} some may recall) and defn- seemed worth doing I
>> presume (pre-dates my involvementT). But then that was all simplified down
>> to just ^:private and it's preferred to compose the pieces rather than copy
>> N things.
>>
>> There used to be a slew of these in the old clojure-contrib (
>> https://github.com/clojure/clojure-contrib/blob/master/modu
>> les/def/src/main/clojure/clojure/contrib/def.clj - but no def- !).
>>
>> How often do you def things anyway (much less private things)?
>>
>> On Monday, February 26, 2018 at 1:50:40 PM UTC-6, Leon Grapenthin wrote:
>>>
>>> I have written enough Clojure so that I can assure you that every few
>>> days when I type ^:private again I am still annoyed by it. Not every time,
>>> but probably every second or third time.
>>>
>>> Its just in the way of the prototyping typing (micro-)flow. SHIFT-6 you
>>> don't hit so often so you have to hit it right. On german keyboards, by the
>>> way, ^ is a much more annoying character to type. Then a colon, did I miss
>>> the colon? What did I want to do again?
>>>
>>> When prototyping an API ns its important to distinguish what is private
>>> and what isn't. If only I could just write def- without any overhead.
>>>
>>> First world aka best language problems, I know...
>>>
>>> But whats left for an enthusiast except bikeshedding? We both know that
>>> a JIRA discussion on this will not happen due to a lack of importance. And
>>> unless somebody manages to convince Rich, this feature won't happen.
>>>
>>> Fair enough. I'd consider myself a power user since 1.5.1 and value its
>>> conservative governance above every other kind.
>>> The "lets not start postfixing lots of macros with -" argument a good
>>> one in general and probably was a good one at the time. But not in this
>>> case because defn and def are the two most used and most elementary top
>>> level forms.
>>>
>>> This argument didn't convince anyone who has asked me about this. The
>>> counter argument goes "I don't want the - postfix for anything else, just
>>> for def because I use it a lot" -rightfully so.
>>>
>>> The lack of def- is just unnecessary typing overhead in lots of cases.
>>> It could be removed at the cost 5m on a beautiful day. I'd appreciate it :)
>>>
>>> On Monday, February 26, 2018 at 6:52:51 PM UTC+1, Alexander Yakushev
>>> wrote:
>>>>
>>>> - Not that often. When I know for certain, I add ^:private. Not like
>>>> it's much more work. If I didn't know ahead of time, I would forget to add
>>>> the private flag in either case.
>>>> - Never.
>>>> - Can't recollect such an event.
>>>> - A few times. As far as I can tell, people appreciate the metadata
>>>> approach since it is unique and powerful. The lack of one particular
>>>> non-critical syntactic sugar is never an issue.
>>>>
>>>> I won't mind having def- as much as I don't mind not having it. Pretty
>>>> much the same as for defn- – Earth wouldn't stop turning if you had to type
>>>> defn ^:private once in a while.
>>>>
>>>> And while I agree with you that it would be somewhat useful,
>>>> bikeshedding only gets you so far.
>>>>
>>>> On Monday, February 26, 2018 at 7:17:05 PM UTC+2, Leon Grapenthin wrote:
>>>>>
>>>>> - How many times do you just write (def ...) instead of (def ^:private
>>>>> ...) because you are not sure whether you need the definition yet, want to
>>>>> save effort, and then you forget to add ^:private later?
>>>>> - How many times have you implemented def- yourself into your project
>>>>> and then used only half of the time because you had to require and :refer
>>>>> the thing from some util namespace which is just as annoying as typing
>>>>> ^:private?
>>>>> - How many times do you use autocomplete on some namespace and find
>>>>> internals because their dev forgot ^:private?
>>>>> - How many times in a year do you have to explain to a Clojure newbie
>>>>> that there is defn- but no def-?
>>>>>
>>>>> IME the statistic strongly supports def- - and I don't see why it
>>>>> would hurt.
>>>>> Having def- in clojure.core will not magically result in having
>>>>> defmacro- and defmulti- and xyz-. Its a false and the only counterargument
>>>>> I have seen.
>>>>>
>>>>> It would be very useful, though.
>>>>>
>>>>> On Monday, February 26, 2018 at 1:44:27 PM UTC+1, Alexander Yakushev
>>>>> wrote:
>>>>>>
>>>>>> Usually, it is better to use metadata rather than create an
>>>>>> exponential explosion of names. Public/private is just one dimension, but
>>>>>> you also have static/non-static, dynamic/non-dynamic, etc. Then you have
>>>>>> functions, vars, macros, perhaps modified functions (like
>>>>>> schema.core/defn). Cartesian product of those would be huge.
>>>>>>
>>>>>> defn- is an exclusion from the rule probably because it is used more
>>>>>> often than others.
>>>>>>
>>>>>> On Monday, February 26, 2018 at 10:58:43 AM UTC+2, Promise. wrote:
>>>>>>>
>>>>>>> `defn-` => `defn`
>>>>>>> 'def-` => `def`
>>>>>>>
>>>>>> --
> 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.
