Changing single-segment namespace (datascript to datascript.core)? about datascript HOT 15 CLOSED

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

from datascript.

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

from datascript.

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

from datascript.

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?

from datascript.

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

from datascript.

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.

from datascript.

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.

from datascript.

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

from datascript.

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.

from datascript.

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:

1. 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.
2. Single-segment namespace names may be considered by some to be aesthetically prettier than multi-segment names.
3. 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.)

from datascript.

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)

from datascript.

@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

from datascript.

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

from datascript.

Fixed in 0.13.0 (datascript → datascript.core)

from datascript.

Thanks!

from datascript.