Why is this bad practice? I'm trying to extend a protocol to js/Function and I
get the following warning:
WARNING: Extending an existing JavaScript type - use a different symbol name
instead of js/Function
I'm trying to create a function that is polymorphic based on the input type
(could be a
Coukd you please post the code that produces that warning? Ideally a
minimal case.
On Thursday, 3 September 2015, Scott Nelson wrote:
> Why is this bad practice? I'm trying to extend a protocol to js/Function
> and I get the following warning:
>
> WARNING: Extending an existing JavaScript type
(defprotocol Foo
(foo [arg]))
(extend-protocol Foo
js/Function
(foo [arg]
(println arg)))
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
Extending a protocol to one of the global JS objects is bad for the same reason
it is bad in Javascript: you are modifying a global object. Your
extend-protocol is like saying Function.prototype.FOO_foo = function(this,
arg){...} in javascript. (The "FOO_foo" is a long namespaced and mangled
pr
Thanks- that worked perfectly. I did not need to extend IFn and I actually got
a runtime error when I tried (perhaps because IFn is a protocol in
ClojureScript?). What are "function"/"object"/ect. in this case,
syntactically? Is there any documentation about this?
Thanks again!
-Scott
--
The "function", "object", "array" symbols are just symbols that have meaning in
the context of the `extend-type` macro, so nothing special syntactically. They
just map internally to the type strings produced by `goog/typeOf`, used for
protocol dispatch.
Just added some documentation to the `ex
OK, thanks. Great documentation by the way. Definitely going to refer to this
from now on.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsu
On Friday, 4 September 2015 20:42:46 UTC+3, Scott Nelson wrote:
> OK, thanks. Great documentation by the way. Definitely going to refer to
> this from now on.
Francis,
Do you have an ide yhy the implementation of `extend-type` for:
1. js types modifies the js type itself
2. while for cljs t
I just looked at the implementation, and it's not done 'from the outside' for
cljs types. `extend-type` adds protocol methods to the type object's
prototype. Only exception is for JS base types (e.g. "function", "number",
"array"). You can see the effects in this gist:
https://gist.github.com
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.
David
On Sun, Sep 6, 2015 at 12:27 PM, Shaun LeBron
wrote:
> I just looked at the impleme
For a little JavaScript WTF and one reason why things are the way the are:
Number.prototype.whatAmI = function() { return typeof(this); };
var x = 1;
x.whatAmI();
"object"
typeof(x)
"number"
Fun times debugging that ...
Cheers,
/thomas
--
Note that posts from new members are moderated - please
thomas,
<<
Number.prototype.whatAmI = function() { return typeof(this); };
var x = 1;
x.whatAmI();
"object"
typeof(x)
"number"
>>
var x = 1 is the same as ... var x = Number(1)
So in both cases x.whatAmI is going to refer to Number.prototype which is
indeed of type [object Number] or as ty
> The point I wanted to make is 'this' without 'new' will refer to the object
> the function is defined on be it 'window' or whatever object.
>
That is incorrect. "this" is the actual number, not window. new or not.
Behavior is probably different for other types. ;)
Number.prototype.addFive
:) Indeed ... different than the usual way, see below for how "new" changes
'this' from being the object whatAmI is defined on to
var T = function() { console.log('constructor called')}
T.prototype = {}
T.prototype.whatAmI = function() {
return {type: Object.prototype.toString.call(this), isEqua
Hmm I think you have those confused.
Take the equivalent from Java:
class MyClass {
}
MyClass x = new MyClass();
Class y = MyClass.class;
or JS:
var MyClass = function() { /* ctor */ };
var inst = new MyClass()
inst != MyClass
inst.prototype == MyClass
inst is an instance of MyClass (prototy
Crossed context here.
What I was pointing to is that trying to create an instance without "new" means
that 'this' in the prototype method whatAmI will point to the prototype itself
rather than the instance. That is what the === proves in the example in my
previous rely. I thought it was the pr
Continuing about the effect of "new" in JS since it is a subject of
exploration/learning at this point, and I believe firmly in knowing your JS
in order to master your CLJS, so maybe one day you could fix a bug in CLJS
itself and be a contributor, which is hard to do in most cases if you don't
know
<<
var MyClass = function() { /* ctor */ };
var inst = new MyClass()
inst.prototype == MyClass
>>
"inst is an instance of MyClass (prototype) but not equal to MyClass."
Yes, no one argues with that. It is an instance of MyClass and it is
obviously !== MyClass,
But saying 'inst.prototype == MyC
>
> var x = T
> x.prototype.whatAmI()
> prints: {type: "[object Object]", isEqualToPrototype: true} < because
> 'this' in whatAmI now points to T.prototype
>
The thing is that you are not supposed to call methods on the prototype
directly.
Your code has this in it:
Object.prototype.toS
<<
Your code has this in it:
Object.prototype.toString.call(this)
which is something you usually do not do. The first argument to the .call
function becomes "this" in the context of the function which is "cheating"
and bypassing prototype inheritance. I consider .call equal to reflection
in Java.
20 matches
Mail list logo