This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (4)
- # boot (18)
- # cider (4)
- # cljsrn (17)
- # clojure (77)
- # clojure-austin (6)
- # clojure-greece (6)
- # clojure-spec (81)
- # clojure-uk (6)
- # clojurescript (32)
- # code-art (2)
- # core-async (12)
- # cursive (1)
- # datomic (1)
- # emacs (15)
- # funcool (1)
- # hoplon (108)
- # om (9)
- # onyx (83)
- # planck (1)
- # re-frame (3)
- # reagent (4)
- # specter (6)
- # spirituality-ethics (4)
- # yada (9)
i haven’t gotten to the bottom of the issue, but i suspect that this, combined with some unit tests that use the page macro where everything gets implicitly added to that namespace might have something to do with it
object is going to be global in any cljs namespace, shouldn’t it be a reserved symbol?
i mean it hasn't been an issue so far, until we added something that adds a protocol to
object in that namespace
if you add the protocol to the fully qualified name of the thing it would be fine i think
any of those lowercase clojurescript types that correspond to
js/Number, etc i would imagine should be reserved.
i’m trying to figure out where they are actually defined in the source, suspect these conventions have something to do with the closure compiler
incidentally, extending the js/Types has always worked for me in practice; the compiler just complains
@jumblerg @micha please correct me if im wrong but do you want to be extending the entire js/Type? When extending types for firebase-cljs i has to use
Type without the
js/ as to not add functions to the entire global type.
@jumblerg: im looking for it, should be in my history somewhere I came across this issue last week 😛
initially i was extending the
js/Node, but ie 8 doesn’t have, or at least expose, the Node type
so i simply put it on
object, which is the equivalent of saying, if there’s not a more concrete implementation provided, call this general implementation instead.
@flyboarder: ah, many thanks! this is exactly the explanation i was looking for, the difference between, say
object was a bit unclear to me.
yes so that may be what you want in some cases but I doubt it should be generally used in a library where you dont know what could exist at runtime
in our case, it is done correctly by extending
number, etc; we’re not modifying the prototype
micha extended the Element prototype, for example, so that other libraries could call, say
.addChild(<someelement>) and remain compatible with hoplon’s model
but i thought thats exactly what using the
js/<Type> variant does was modify the prototype
the reason for extending
object, istead of
js/Object according to dnolen, is for optimization reasons
hmmm i guess this means i can extend
object for dynamic types that only exist at runtime
i'm guessing it would include a check for
(satisfies? IFoo x) and then dispatch on type in a case analysis?
i’ll check in a moment, running more ie 8 tests atm with the dev tools stripped out of the pipline
neat little fn i just made: https://gist.github.com/2355d19343c693c853fe20f2f762307b
@dnolen: thanks for chiming in. i keep reading as much, but do you have a concrete example in mind?
…and we’ve established now, with a bit of research, that extending a js/<Type> does in fact modify the corresponding prototype
@dnolen: where are the corresponding lowercase types used by clojurescript introduced into the source?
i guess i wasn’t clear in my question, i mean the definitions of the lowercase types themselves. i mean, i can extend
object with no optimizations; where is
object, as opposed to
we do this for all the native JS types - it’s a syntax thing handled by the
deftype style macros
no worries. the semantics of things become a lot clearer when i can step through the source.
extend-type macro is the thing to look at which all the
deftype style macros will emit