Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

No reason to avoid single-segment namespaces.#100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
llasram wants to merge1 commit intobbatsov:masterfromllasram:single-segment

Conversation

llasram
Copy link
Contributor

Clojure namespaces withgen-class map to classes with the same full name as the namespace. This produced some concern about single-segment namespaces being equivalent to Java package-less classes and a cargo-culting avoidance of single-segment namespaces. In practice non-gen-class single-segment namespaces do not appear to cause any known problems, and have begun to appear in libraries by well-respected Clojure community members, such as Brandom Bloom’s backtick [1].

[1]https://github.com/brandonbloom/backtick

daveliepmann reacted with thumbs down emoji
Clojure namespaces with `gen-class` map to classes with the same fullname as the namespace.  This produced some concern about single-segmentnamespaces being equivalent to Java package-less classes and acargo-culting avoidance of single-segment namespaces.  In practicenon-`gen-class` single-segment namespaces do not appear to cause anyknown problems, and have begun to appear in libraries by well-respectedClojure community members, such as Brandom Bloom’s backtick [1].[1]https://github.com/brandonbloom/backtick
@bbatsov
Copy link
Owner

Clojure namespaces with gen-class map to classes with the same full name as the namespace. This produced some concern about single-segment namespaces being equivalent to Java package-less classes and a cargo-culting avoidance of single-segment namespaces.

Yeah, this is why we introduced this rule in the first place. What you're saying sounds reasonable, but I'd like to do some digging first (and perhaps hear more comments).

Btw, probably it still makes some sense to suggest that projects should use multi-segment namespaces when they have more than a single namespace. I also have a feeling people are abusing thexxx.core namespace, but we have lein to blame for that. :-)

@arrdem
Copy link
Contributor

I have no particular objection to single segment namespaces.gen-class is a feature I almost never reach for, and I've found it expedient in the past, and for small namespaces.

@puredanger
Copy link
Collaborator

Namespaces exist to disambiguate names. Using a single segment namespace puts you in direct conflict with everyone else using single segment namespaces, thus making it more likely you will conflict with another code base.

So, for libs, I think it's a very good idea to use a first segment for context vs every other lib you might include. Within your own private app of course, you can do whatever you like. :)

daveliepmann, mrrodriguez, danielcompton, and NoahTheDuke reacted with thumbs up emoji

@alexander-yakushev
Copy link

For what it is or isn't worth, Android doesn't support single-level packages, probably for good reasons. Besides, dot in a package name is a useful telltale sign for different tools (like clojure-mode) to know something is a package/namespace or a class.

@danielcompton
Copy link
Collaborator

Single segment namespaces haveproblems in ClojureScript as well.

[David Nolen] Compiler support for single segment namespaces has always been spotty and there's no intention to improve it. There are fundamental semantic issues - for example if you have a DOM element with a CSS id and you haven't supplied a namespace but you goog.require one with that name it will return the DOM element. Good luck debugging that.

Single segment namespaces are nearly alway representative of a problem waiting to manifest. If you want to use them then you can suppress the warning in your build options.

You'll get warnings in ClojureScript by default when compiling single segment namespaces.

IMO everything in the design of Clojure, the JVM, and ClojureScript seems to be pushing away from single segment namespaces. The only benefit from single segment namespaces (I think?) is a slightly more elegant ns declaration. While that's nothing to be sniffed at, IMO it's not a big enough gain. People can do whatever they want in their own code, but in the de facto style guide for Clojure, I think single segment namespaces should be avoided.

daveliepmann, mrrodriguez, dustingetz, oxalorg, and kah-ell reacted with thumbs up emoji

@bbatsov
Copy link
Owner

I guess the best we can do is to extend the rationale behind the existing rule then. In general a lot of rules in the guide could benefit from extended rationale, but I've been pretty short on time lately.

@dijonkitchen
Copy link
Contributor

Should this PR be closed now given the above discussion? Maybe just have the default be something likename.core instead of justname.

@bbatsov
Copy link
Owner

I didn't close it simply because for me it served as a reminder to move some of this conversation to the style guide. Alas, I never got to doing this. :-)

@bbatsov
Copy link
Owner

And I finally converted this reminder to improvements in the guide. Thanks to everyone who participated in the conversation!

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

7 participants
@llasram@bbatsov@arrdem@puredanger@alexander-yakushev@danielcompton@dijonkitchen

[8]ページ先頭

©2009-2025 Movatter.jp