|
Kobayashi posted:I don't remember what I was doing, but the other day I ran into the arguments keyword and I feel like I've just fallen down the rabbit hole. I've always known that Javascript is a "prototype based language," and that "functions are first class objects," but I don't think I really "get" what any of that means. With arguments, it seems that function overloading doesn't work the same way that it does in object-oriented languages -- I can call a function with whatever arguments I want and welp, YOLO. Just a nit-picky technical thing but JavaScript's arguments behavior doesn't have anything to do with being a prototype-based language and method overloading is not an inherent feature of object-oriented languages. Method-overloading is typically a feature of languages that rely on statically-typed method signatures. Some OOP languages have it (Java, C#) and some don't (Smalltalk, Objective-C). JavaScript does not have statically-typed method definitions and therefore "overloading" doesn't make sense (because there's no information to the interpreter to tell which "foo" method you're trying to call). arguments is a particular quirk of JavaScript but other languages have something sorta similar (C# has params arguments, C/C++ has variadic functions, and nearly every dynamic language has *some* way of passing arbitrary arg lists to methods). Dr Monkeysee fucked around with this message at 22:07 on Aug 15, 2014 |
# ? Aug 15, 2014 22:04 |
|
|
# ? Jun 5, 2024 19:32 |
|
Dr Monkeysee posted:arguments is a particular quirk of JavaScript but other languages have something sorta similar (C# has params arguments, C/C++ has variadic functions, and nearly every dynamic language has *some* way of passing arbitrary arg lists to methods). The main difference between Javascript's arguments and other languages is that arguments a) contains all of the passed arguments and b) is not actually an array. Any other language I can think of that supports variable argument definitions has both an explicit way of defining access to them (*args in ruby) and the list of variable arguments is not some special "object".
|
# ? Aug 16, 2014 03:57 |
|
JS arguments, pre-strict is a 2-way binding to the arguments themselves, which I guess is a little unusual. It also includes the named arguments, and not just the variadic "overflow". The non-Array-ness probably cost me 6 months off my life, it's hard to justify given what we know in TYOOL 2014 (or 1999).
|
# ? Aug 16, 2014 04:07 |
|
The book "Effective JavaScript", which was my introduction to the JavaScript rabbit hole, recommends converting it to an Array if you are going to use it. At least I think I remember it saying that, I don't have it on hand at the moment.code:
code:
Subjunctive posted:JS arguments, pre-strict is a 2-way binding to the arguments themselves, which I guess is a little unusual. It also includes the named arguments, and not just the variadic "overflow". The non-Array-ness probably cost me 6 months off my life, it's hard to justify given what we know in TYOOL 2014 (or 1999). Can you elaborate a little on the implications of that 2-way binding? Are you saying the strict pragma prevents that binding? Does putting the arguments into an Array before working with them accomplish the same thing (aside from also enabling the use of Array methods on the arguments collection)? Malfeasible fucked around with this message at 04:45 on Aug 16, 2014 |
# ? Aug 16, 2014 04:27 |
|
Malfeasible posted:The book "Effective JavaScript", which was my introduction to the JavaScript rabbit hole, recommends converting it to an Array if you are going to use it. At least I think I remember it saying that, I don't have it on hand at the moment. The ugliness of that haunts me at least weekly. Would Arguments.prototype.toArray() have killed us? No, no it would not have. quote:I like the idea of using an options object if there are going to be a lot of arguments. I find it irritating to have to worry about what order all my args are in. I think at least one JS engine optimizes away the object creation and assignments if the extraction in the callee is straightforward enough, too. It's a good pattern.
|
# ? Aug 16, 2014 04:37 |
|
Subjunctive posted:JS arguments, pre-strict is a 2-way binding to the arguments themselves, which I guess is a little unusual. It also includes the named arguments, and not just the variadic "overflow". The non-Array-ness probably cost me 6 months off my life, it's hard to justify given what we know in TYOOL 2014 (or 1999). I did a quick test in Firebug to see this in action. code:
named argument: one named argument: two arguments: one arguments: two Array[0]: one Array[1]: two named argument: edited 1 named argument: edited 2 arguments: edited 1 arguments: edited 2 Array[0]: one Array[1]: two Output with "use strict" pragma: named argument: one named argument: two arguments: one arguments: two Array[0]: one Array[1]: two named argument: edited 1 named argument: edited 2 arguments: one arguments: two Array[0]: one Array[1]: two
|
# ? Aug 16, 2014 05:38 |
|
Skiant posted:They have almost a whole page inside explaining that they know the difference for assholes like you. So?
|
# ? Aug 16, 2014 12:53 |
|
Skiant posted:Secrets of the Javascript ninja or Javascript Allongé might be good reads. qntm posted:Which has a samurai on the cover... Skiant posted:They have almost a whole page inside explaining that they know the difference for assholes like you. qntm posted:So? The moral of the story is: Don't judge a book by its cover.
|
# ? Aug 16, 2014 16:27 |
|
John Resig is a huge ukiyo-e nerd (he runs http://ukiyo-e.org/) so I feel like that explains the cover adequately. Also, he's a really smart guy and knows javascript well.
|
# ? Aug 16, 2014 17:00 |
|
Peanut and the Gang posted:The moral of the story is: Don't judge a book by its cover. Well, sure, it would be difficult for the interior of this book to be dumber than its exterior.
|
# ? Aug 16, 2014 18:16 |
|
necrotic posted:The main difference between Javascript's arguments and other languages is that arguments a) contains all of the passed arguments and b) is not actually an array. Any other language I can think of that supports variable argument definitions has both an explicit way of defining access to them (*args in ruby) and the list of variable arguments is not some special "object".
|
# ? Aug 16, 2014 20:27 |
|
necrotic posted:The main difference between Javascript's arguments and other languages is that arguments a) contains all of the passed arguments and b) is not actually an array. Any other language I can think of that supports variable argument definitions has both an explicit way of defining access to them (*args in ruby) and the list of variable arguments is not some special "object". arguments is definitely quirky. I just wanted to stress there's nothing particularly OOP or prototype-y about it. It's just a thing that has similar parallels in other, unrelated, languages.
|
# ? Aug 17, 2014 08:27 |
|
Finally resorting to learning from the ground up, I'm reading through Mozilla's Working With Objects tutorial. I'm confused by the following snippet:JavaScript code:
|
# ? Aug 19, 2014 18:28 |
|
Newf posted:Finally resorting to learning from the ground up, I'm reading through Mozilla's Working With Objects tutorial. I'm confused by the following snippet: for (var i in obj) iterates obj's own and inherited properties. obj.hasOwnProperty returns true only for non-inherited properties. JavaScript code:
code:
|
# ? Aug 19, 2014 18:47 |
|
Newf posted:Finally resorting to learning from the ground up, I'm reading through Mozilla's Working With Objects tutorial. I'm confused by the following snippet: I don't see a forEach loop? If you don't use hasOwnProperty you will get properties from further up the prototype chain. The in operator iterates over all properties.
|
# ? Aug 19, 2014 18:48 |
|
Haven't been able to find this in google, but if I set a for loop like so:code:
code:
|
# ? Aug 19, 2014 19:56 |
|
Raskolnikov2089 posted:I'm a bit confused since I see examples both ways, without an indication of which is best. Use more functions. It's the only scope Javascript has
|
# ? Aug 19, 2014 19:59 |
|
Raskolnikov2089 posted:
Yes, you are. Congrats, you're well on your way to creating benchmarks that don't test what they think they're testing!
|
# ? Aug 19, 2014 22:00 |
|
Newf posted:Finally resorting to learning from the ground up, I'm reading through Mozilla's Working With Objects tutorial. I'm confused by the following snippet: I'm just gonna throw this out there since I learned it recently and felt like a dolt for doing things the hard way, but Object.keys is a much better (and faster) way to iterate over an object's keys, like so: JavaScript code:
|
# ? Aug 20, 2014 02:05 |
|
Be aware that Object.keys() is not supported in < IE9, which can be a bitch if, like me, you're forced to support IE8. Instead take a look at lo-dash for a whole ton of javascript short cuts. JavaScript code:
|
# ? Aug 20, 2014 02:21 |
|
v1nce posted:Be aware that Object.keys() is not supported in < IE9, which can be a bitch if, like me, you're forced to support IE8. That's what the es5 shim and sham libraries are for, though. lodash is nice but I think including it just for backwards compatibility is kinda rear end-backwards if you don't need anything else in it and just bloats your modern-browser targeted code.
|
# ? Aug 20, 2014 03:16 |
|
Chenghiz posted:I'm just gonna throw this out there since I learned it recently and felt like a dolt for doing things the hard way, but Object.keys is a much better (and faster) way to iterate over an object's keys, like so: Is that faster? I guess if forEach and keys are self-hosted, and the function call is inlined? I'm surprised that it can beat for-in, even in those cases, without really aggressive optimizations that I don't think any engines do. (Tracing JITs would have the best odds, I'd think, but no major engine traces these days. ) Edit: built-in forEach is often slower than a JS version of the same, because of native/script transition costs. That was a bit frustrating to realize after adding the "Array extras", but modern JITs get pretty close when self-hosting those cases. Subjunctive fucked around with this message at 03:21 on Aug 20, 2014 |
# ? Aug 20, 2014 03:19 |
|
Subjunctive posted:Is that faster? I guess if forEach and keys are self-hosted, and the function call is inlined? I'm surprised that it can beat for-in, even in those cases, without really aggressive optimizations that I don't think any engines do. (Tracing JITs would have the best odds, I'd think, but no major engine traces these days. ) IIRC for-in is pretty much the slowest native for-loop in JS. Citing speed is probably unfair of me though because at the end of the day they're all quite fast enough for 99% of applications. I just think Object.keys().forEach is more clear and it avoids the problem that Object.hasOwnProperty() is trying to solve at the same time.
|
# ? Aug 20, 2014 03:41 |
|
Building a mobile(ipad) based web app. I am using the jQuery to perform autocomplete. The autocomplete is working however I am unable to scroll through the items. I have attempted to accomplish this via CSS however it does not seem to work. I would like to use javascript to add scroll to the autocomplete, however it seems to not work. Was attempting to use something similar to below to add scroll, but was unsuccessful. code:
|
# ? Aug 20, 2014 14:34 |
|
Raskolnikov2089 posted:Haven't been able to find this in google, but if I set a for loop like so: I recommend using strict mode whenever possible (generally all new scripts). It forces you to declare all globals explicitly, with var. Attempting to assign to any undeclared variable will cause an error.
|
# ? Aug 20, 2014 15:43 |
|
DholmbladRU posted:Building a mobile(ipad) based web app. I am using the jQuery to perform autocomplete. The autocomplete is working however I am unable to scroll through the items. I have attempted to accomplish this via CSS however it does not seem to work. I would like to use javascript to add scroll to the autocomplete, however it seems to not work. I was finally able to figure this out. code:
|
# ? Aug 20, 2014 16:46 |
|
Reading some documentation (for Sequelize) and it has this: code:
|
# ? Aug 21, 2014 21:07 |
|
fuf posted:Reading some documentation (for Sequelize) and it has this: It's trying to convert it to a bool (null/undefined/0/"" would become false), but actually it's superfluous because if-statements already convert the condition to bools anyway.
|
# ? Aug 21, 2014 21:10 |
|
That makes sense, thanks.
|
# ? Aug 21, 2014 21:31 |
|
Peanut and the Gang posted:It's trying to convert it to a bool (null/undefined/0/"" would become false), but actually it's superfluous because if-statements already convert the condition to bools anyway. Yeah that's bad js developer smell seeing the !!.
|
# ? Aug 22, 2014 00:19 |
|
Bruegels Fuckbooks posted:Yeah that's bad js developer smell seeing the !!. Is this necessarily true? I find myself going back and forth a lot on how snappy my judgements on cargo cult practices are. !! seems at least potentially useful as a shorthand for to replace the comment 'this variable may or may not be a bool at the present moment, but moving forward we're only concerned with treating it as a bool'. Self-commenting code, etc.
|
# ? Aug 22, 2014 13:09 |
|
It's in an if statement. It will already be cast to a bool for the purposes of the if statement. It doesn't matter if you cast it yourself.
|
# ? Aug 22, 2014 14:08 |
|
Suspicious Dish posted:It's in an if statement. It will already be cast to a bool for the purposes of the if statement. It doesn't matter if you cast it yourself. Yeah, but the point is that the cast, y'know, casts it for future use, which may be what you want. JavaScript code:
JavaScript code:
|
# ? Aug 22, 2014 14:26 |
|
Newf posted:Please disregard everything I ever say. Probably put me on ignore. Okay.
|
# ? Aug 22, 2014 15:16 |
|
I'm having an issue in Drupal which I'm pretty sure is JS related but I'm getting no errors or warning in the console at all so I have no idea where to look for a solution. I have created a content type with a file field that allows unlimited values. When I upload a file I am expecting to be able to immediately upload another file. but what actually happens is the upload box disappears, meaning I have to save the node and re-edit it in order to upload another file both these examples have exactly the same content type settings, both running the same version of Drupal. I'm not getting any JS errors or anything. Any ideas on why this is happening?
|
# ? Aug 22, 2014 15:48 |
|
Does anyone know of a node libary similar to rail's public_activity, for creating activity feeds for users (similar to your facebook news feed).
|
# ? Aug 22, 2014 19:49 |
|
Chrome dev tools lets you edit js source of a remote website from within the browser, is there any way to just reload the page with those local modifications applied? Otherwise what is the loving point of letting you edit any of this in browser.
|
# ? Aug 23, 2014 18:03 |
|
In the project I'm working on right now, I very often need to loop until a certain condition is met or an amount of time has passed. Since I do it so often, I want to move the code into a generic function to avoid rewriting the same thing again and again. The condition is arbitrary and varies widely depending on the function. The most succinct way I can think of doing this is passing the condition to the function in a string and eval'ing it. I'm wondering if anyone else has any ideas?code:
foxy boxing babe fucked around with this message at 05:11 on Aug 24, 2014 |
# ? Aug 24, 2014 04:40 |
|
Don't do that. Use condition as a function, it'll be a little more verbose but it's more flexible, reliable, and secure. You also properly maintain variable scope.code:
|
# ? Aug 24, 2014 04:45 |
|
|
# ? Jun 5, 2024 19:32 |
|
Yeah, you're right. I didn't like the verbosity of condition as a function, and using eval looked prettier and easier to read, but this is the better choice.
|
# ? Aug 24, 2014 05:08 |