Fork me on GitHub
#hoplon
<
2016-06-18
>
micha00:06:42

perhaps you want cljs.core/object or something

jumblerg00:06:42

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

jumblerg00:06:59

object is going to be global in any cljs namespace, shouldn’t it be a reserved symbol?

micha00:06:50

is that true?

micha00:06:18

i mean it hasn't been an issue so far, until we added something that adds a protocol to object in that namespace

micha00:06:33

if you add the protocol to the fully qualified name of the thing it would be fine i think

micha00:06:43

like you can make a function named map if you want

jumblerg00:06:44

i need to check, but clojurescript has these lowercase types

micha01:06:01

ah right but it gets referred

jumblerg01:06:07

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

micha01:06:23

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

jumblerg01:06:56

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

jumblerg01:06:59

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

micha01:06:44

it's interesting that no warnings are generated

micha01:06:04

what are the lowercase object etc for?

jumblerg01:06:10

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

micha01:06:20

what does it say?

jumblerg01:06:50

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

micha01:06:25

hm, what's the difference?

micha01:06:38

like you need to extend js/Object in your case

micha01:06:44

some other thing won't work

micha01:06:03

and why is it warning you?

micha01:06:14

is there an issue with doing that?

jumblerg01:06:01

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

jumblerg01:06:21

Object is a protocol

micha01:06:02

js/Object isn't though

micha01:06:11

cljs.core/Object could be

jumblerg01:06:19

there are all these types

jumblerg01:06:40

that correspond to the js/Types

jumblerg01:06:30

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

jumblerg01:06:22

the type annotations it uses

jumblerg01:06:32

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

micha01:06:56

yeah it might be possible to annotate to suppress the warnings

flyboarder16:06:39

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

flyboarder16:06:53

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

jumblerg16:06:11

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

flyboarder16:06:34

@jumblerg: im looking for it, should be in my history somewhere I came across this issue last week 😛

jumblerg16:06:32

initially i was extending the js/Node, but ie 8 doesn’t have, or at least expose, the Node type

jumblerg16:06:53

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.

jumblerg16:06:16

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

flyboarder16:06:50

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

flyboarder16:06:41

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

flyboarder16:06:28

But in hoplon case im not sure how it should go

jumblerg16:06:29

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

jumblerg16:06:35

although there could be cases where we want to

flyboarder16:06:54

awesome, on same page now i believe 🙂

jumblerg16:06:41

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

micha16:06:34

protocols don't touch the object itself though

micha16:06:51

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

micha16:06:03

protocols are just a name munging scheme in the compiler

flyboarder16:06:51

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

jumblerg16:06:07

reading further down the thread….

micha16:06:14

protocol != prototype

micha16:06:24

lol confusingly similar though

micha16:06:07

ah i think i'm wrong actually

jumblerg16:06:08

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

jumblerg16:06:22

“”"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.””"

flyboarder16:06:47

lol group learning moment

micha16:06:40

excellent!

jumblerg16:06:04

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

flyboarder16:06:52

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

micha16:06:45

"deoptimization"

micha16:06:50

great word

micha16:06:31

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

micha16:06:42

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

micha16:06:05

if it can't just call the prototype method

jumblerg16:06:59

i’ll check in a moment, running more ie 8 tests atm with the dev tools stripped out of the pipline

dnolen16:06:24

@jumblerg: it’s not just for optimization reasons

dnolen16:06:42

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

jumblerg16:06:29

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

dnolen16:06:51

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

dnolen17:06:00

with zero knowledge of what that will do to other code

jumblerg17:06:17

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

dnolen17:06:47

yes so something you should never do in a libray

dnolen17:06:49

global effect

dnolen17:06:09

in applications somewhat less troubling if used tastefully

jumblerg17:06:11

makes sense

dnolen17:06:40

advanced optimizations will munge properties

dnolen17:06:49

so you’re extension on Object could easily become

dnolen17:06:29

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

jumblerg17:06:31

that could clobber all sorts of things

jumblerg17:06:39

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

dnolen17:06:53

@jumblerg: I answered that question

dnolen17:06:04

advanced optimization

jumblerg17:06:24

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?

dnolen17:06:57

@jumblerg: oh sorry misunderstood

dnolen17:06:25

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

dnolen17:06:34

object, string etc.

jumblerg17:06:41

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

dnolen17:06:30

and you can look around for where that’s used

dnolen17:06:07

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

jumblerg17:06:37

ah, awesome - i was trying to find that

jumblerg17:06:57

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

flyboarder17:06:40

@dnolen: much appreciate the clarity!