Changing single-segment namespace (datascript to datascript.core)?

In Clojure, single-segment namespace names such as datascript are discouraged versus multi-segment names such as datascript.core, both as a matter of style and as a matter of being on the JVM (Stack Overflow thread; Google Group thread).

In ClojureScript, single-segment namespaces are similarly discouraged as a matter of style, but they also have problems with Google Closure—the latest version of ClojureScript (0.0-2814) has a new warning against single-segment namespaces for that reason.

[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.

(See also: conversation between David Nolen and Luke VanderHart.)

It would be a breaking change, but it might be best for the future before version 1.0 to change the datascript namespace to something like datascript.core, and switch the current datascript.core to something like datascript.impl or whatever, in order to avoid the new ClojureScript compiler warning, and especially in case a Clojure-for-JVM version ever is created (#54).

Thank you so much for DataScript. It is absolutely amazing.

+1 I'm going to plus one this. I designed figwheel to not hot load code with warnings, I have to turn off this very helpful feature when I use datascript.

Revision:
Actually thats not true it only warns on initial analysis.

+1 for the reasons namespaces exist in general. I find them very useful and it's a pity so many great libraries in clj / cljs land don't make proper use of them.

Well, I actually don’t understand the problem of single-segment namespace. What breaks if I use one? Even in Clojure?

It's a ClojureScript issue:
http://dev.clojure.org/jira/browse/CLJS-1004
clojure/clojurescript@dc47f1f

And all the resources linked by the OP. Not enough?

Yes, I’ve seen it. Still don’t understand what breaks if I use
single-segment namespace. Unability to define

seems
like something I can live with

On Fri Feb 20 2015 at 01:39:09 GMT+6 Bruce Hauman notifications@github.com
wrote:

It's a ClojureScript issue:
http://dev.clojure.org/jira/browse/CLJS-1004
clojure/clojurescript@dc47f1f
clojure/clojurescript@dc47f1f

—
Reply to this email directly or view it on GitHub
#57 (comment).

Basically you are saying: I am the only one to release a library with the namespace datascript. It's just a way to avoid ambiguity in naming.
Usually you would choose a ns like: com.yourdomain.datascript or if you don't own a domain com.github.tonsky.datascript.

I guess this just became a common practice because it has some small advantages compared to the slightly longer import name.

sveri: No, that is not the reason. The problem is indeed that the dependency resolution mechanism returns a DOM node with the same name if present (see http://dev.clojure.org/jira/browse/CLJS-1004)

However, I would also like to see that changed in datascript because I don't want to turn off the "do not load if there are warnings" feature in figwheel.

I know that these reasons are not the same, I just wanted to add some more reasons to switch to a different namespace.

Just to be clear. As I mentioned above you don't have to turn off the Figwheel feature the prevents the loading of code that is generating warnings. The ClojureScript single segment namespace warning only occurs once on initial analysis.

So there is really no show stopper here. This is just a nice to have.

I would add that the possibility of someone having a DOM Id of "datascript" is much higher now that datascript exists. And it's a really tough one to debug, as code is getting loaded a DOM element gets returned instead???

But I don't see this as something that requires urgent attention at all.

What breaks if I use one? Even in Clojure?

For Clojure, the main reason appears to be the that in the Stack Overflow page above, which says, “If you pre-compile a one-segment Clojure namespace, you'll get a Java class in the default package. If anyone at any time wants to use your library from Java, he will be stopped dead by this triviality,” though I haven’t yet tested this myself.

The main thing is that changing the namespace doesn't seem very costly and brings benefits. The only anti-change arguments that I can think of include:

Changing a library's namespace breaks backwards compatibility and this may be too costly for its current users, even for pre-1.0 libraries such as DataScript.
Single-segment namespace names may be considered by some to be aesthetically prettier than multi-segment names.
Refactoring the library's source code for the namespace changes may be difficult.

None of these three reasons to not change it seem very compelling to me by themselves, though I may be mistaken. The arguments for changing it seem more compelling to me: single-segment names interact with state in users' JavaScript programs in hidden and unexpected ways, creating a leaky abstraction; they may interfere with Java interoperability; and they are inconsistent with other Clojure/ClojureScript libraries as well as the core Clojure API itself—even if these might not be show-stoppers, they do seem more serious than any of the three anti-change reasons above.

Nevertheless, I suspect that the library creator finds one of those anti-change reasons (or another reason) compelling enough to keep single-segment namespaces—though I would be interested in knowing which ones they happen to be: backwards compatibility, aesthetics, refactoring difficulty, or something else. (DataScript is still pre-1.0, after all.)

I get these errors in the node repl and can't seem to use the datascript.query namespace because of it:

WARNING: datascript is a single segment namespace at line 1 .repl/datascript.cljc
WARNING: datascript is a single segment namespace at line 1 file:/home/gary/.m2/repository/datascript/datascript/0.11.1/datascript-0.11.1.jar!/datascript.cljc

query.core> (require '[datascript.query :as q])
nil
query.core> (q/q
             '[:find ?e
               :where [?e :age 42]])
ExceptionInfo ReferenceError: datascript is not defined
    at repl:1:69
    at repl:9:3
    at [stdin]:41:34
    at b (domain.js:183:18)
    at Domain.run (domain.js:123:23)
    at Socket.<anonymous> ([stdin]:40:25)
    at Socket.EventEmitter.emit (events.js:95:17)
    at Socket.<anonymous> (_stream_readable.js:746:14)
    at Socket.EventEmitter.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:408:10)  clojure.core/ex-info (core.clj:4591)

@gtrak

@gtrak Eventually I’ll fix this, for now use {:warnings {:single-segment-namespace false}} compiler option. Also you should require datascript, not datascript.query, and use datascript/q fn

Just a FYI, I had the following issue due this single namespace (I feel kind of stupid about it):

(ns my-namespace
 (:require  [adgoji.datascript :as datascript]
            [datascript :as d])

(defonce conn (datascript/setup-conn))

This resulted in

Uncaught TypeError: Cannot read property 'call' of undefined

setup-conn was really defined in adgoji.datascript though. It took me a while before I figured datascript was not only available via alias d but also as datascript itself

Fixed in 0.13.0 (datascript → datascript.core)

Thanks!

Navigation Menu

Repository navigation

Changing single-segment namespace (datascript to datascript.core)? #57

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Changing single-segment namespace (datascript to datascript.core)? #57

Description

Activity

bhauman commented on Feb 18, 2015

sveri commented on Feb 18, 2015

tonsky commented on Feb 19, 2015

bhauman commented on Feb 19, 2015

tonsky commented on Feb 19, 2015

sveri commented on Feb 20, 2015

bendisposto commented on Feb 20, 2015

sveri commented on Feb 20, 2015

bhauman commented on Feb 20, 2015

cigitia commented on Feb 23, 2015

gtrak commented on May 13, 2015

tonsky commented on May 14, 2015

jeroenvandijk commented on Aug 28, 2015

tonsky commented on Sep 20, 2015

jeroenvandijk commented on Sep 21, 2015

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions