Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-11-19

Channels

#sci
<
2023-11-19
>
Ingy döt Net21:11:18

It seems like SCI treats foo.bar and foo/bar the same. Is this expected? 

$ clj -M -e 'clojure.core/inc'
#object[clojure.core$inc 0x5c3b6c6e "clojure.core$inc@5c3b6c6e"]
$ clj -M -e 'clojure.core.inc'
Syntax error (ClassNotFoundException) compiling at (REPL:0:0).
clojure.core.inc

Full report at:
/tmp/clojure-10423880322428291732.edn
$ bb -e 'clojure.core/inc'
#object[clojure.core$inc 0x6f14fb4a "clojure.core$inc@6f14fb4a"]
$ bb -e 'clojure.core.inc'
#object[clojure.core$inc 0x6f14fb4a "clojure.core$inc@6f14fb4a"]

borkdude21:11:50

That's pretty weird, never saw that before :)

Ingy döt Net21:11:53

first noticed it in my ys usage of sci, so tried with bb and got the same thing

borkdude21:11:17

It is because of the mechanism to resolve custom types. Custom types are completely fake in SCI but in clojure they are host objects, like: 

(ns foo)
(deftype Foo [])
now foo.Foo refers to a type. In SCI this type just lives in the foo namespace but to be compatible it accepts foo.Foo

borkdude21:11:06

I could lock this behavior down some more, but I would just consider it undefined behavior that you shouldn't rely on

Ingy döt Net22:11:37

That's fine with me. This isn't causing me any problems at the moment. Just seemed strange so I thought I'd bring it up.

👍 1