@micha: https://github.com/hoplon/hoplon/blob/master/src/hoplon/core.cljs#L437

hah

perhaps you want cljs.core/object or something

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?

is that true?

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

like you can make a function named map if you want

i need to check, but clojurescript has these lowercase types

ah right but it gets referred

but in that case, you get a warning, and have to explicitly exclude it

if you change that to html-object does it fix?

that’s my next thing to try. but regardless, i wonder if we should anyway.

any of those lowercase clojurescript types that correspond to js/Object, js/String, js/Number, etc i would imagine should be reserved.

it's interesting that no warnings are generated

what are the lowercase object etc for?

yeah, it is. the compiler yells at me if i use js/Object though.

what does it say?

it warn’s that you are extending a javascript type, and prompts you to use, say string lowercase, instead.

hm, what's the difference?

like you need to extend js/Object in your case

some other thing won't work

and why is it warning you?

is there an issue with doing that?

one sec

WARNING: Extending an existing JavaScript type - use a different symbol name instead of js/Object e.g object at line 76 /Users/jumblerg/.boot/cache/tmp/Users/jumblerg/Development/libs/hoplon/4tx/-rcsl8f/hoplon/core.cljs
WARNING: Extending an existing JavaScript type - use a different symbol name instead of js/String e.g string at line 81 /Users/jumblerg/.boot/cache/tmp/Users/jumblerg/Development/libs/hoplon/4tx/-rcsl8f/hoplon/core.cljs
WARNING: Extending an existing JavaScript type - use a different symbol name instead of js/Number e.g number at line 86 /Users/jumblerg/.boot/cache/tmp/Users/jumblerg/Development/libs/hoplon/4tx/-rcsl8f/hoplon/core.cljs

Object is a protocol

js/Object isn't though

cljs.core/Object could be

right

there are all these types

https://github.com/clojure/clojurescript/blob/202cfcf045cf86d3ab295cbf16a347569b652647/src/cljs/clojure/data.cljs#L83-L108

that correspond to the js/Types

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

the type annotations it uses

incidentally, extending the js/Types has always worked for me in practice; the compiler just complains

yeah it might be possible to annotate to suppress the warnings

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

https://github.com/degree9/firebase-cljs/blob/master/src/firebase_cljs/auth.cljs#L96

It was my understanding that using js/Object would modify the Object prototype

@flyboarder: do you have suggested reading on this subject?

@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

https://groups.google.com/d/msg/clojurescript/MKEZ9CBU77o/h7ejrbNFCgAJ

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 js/Object and object was a bit unclear to me.

yeah it’s still a bit fuzzy which i why I was asking 🙂

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

But in hoplon case im not sure how it should go

in our case, it is done correctly by extending object, string, number, etc; we’re not modifying the prototype

although there could be cases where we want to

awesome, on same page now i believe 🙂

micha extended the Element prototype, for example, so that other libraries could call, say .addChild(<someelement>) and remain compatible with hoplon’s model

protocols don't touch the object itself though

extending a protocol is not the same as manipulating an object's prototype

protocols are just a name munging scheme in the compiler

but i thought thats exactly what using the js/<Type> variant does was modify the prototype

no

reading further down the thread….

protocol != prototype

lol confusingly similar though

corrected^

ah i think i'm wrong actually

the reason for extending object, istead of js/Object according to dnolen, is for optimization reasons

“”"It's not safe to change the JavaScript base types directly - besides the obvious down sides of global changes to types you don't control, this often triggers dramatic de-optimization in JavaScript engines.””"

https://gist.github.com/shaunlebron/a98a05b47a1521b58a6b

lol group learning moment

excellent!

ah, good link. i just produced similar js output in my repl.

hmmm i guess this means i can extend object for dynamic types that only exist at runtime

"deoptimization"

great word

it would be interesting to see what (defn f [x] (foo x)) compiles to in that namespace

i'm guessing it would include a check for (satisfies? IFoo x) and then dispatch on type in a case analysis?

if it can't just call the prototype method

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

@jumblerg: it’s not just for optimization reasons

changing the Object prototype is guaranteed to create all kinds of problems

@dnolen: thanks for chiming in. i keep reading as much, but do you have a concrete example in mind?

@jumblerg: you’re changing the root global Object type

with zero knowledge of what that will do to other code

…and we’ve established now, with a bit of research, that extending a js/<Type> does in fact modify the corresponding prototype

yes so something you should never do in a libray

global effect

in applications somewhat less troubling if used tastefully

makes sense

advanced optimizations will munge properties

so you’re extension on Object could easily become

= ….

now you can play Russian Roulette with code that might define “ac” property

that could clobber all sorts of things

@dnolen: where are the corresponding lowercase types used by clojurescript introduced into the source?

@jumblerg: I answered that question

advanced optimization

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 js/Object, introduced?

@jumblerg: oh sorry misunderstood

we do this for all the native JS types - it’s a syntax thing handled by the deftype style macros

object, string etc.

no worries. the semantics of things become a lot clearer when i can step through the source.

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L1208

and you can look around for where that’s used

extend-type macro is the thing to look at which all the deftype style macros will emit

ah, awesome - i was trying to find that

i didn’t realize you were in this channel. many thanks!

np

@dnolen: much appreciate the clarity!