Elvis: It wouldnt, it would just move the complexity around
Marstaller: Tcsc: yes, but from a readability/understandability perspective, it’s best how it is, I think
Elvis: I dont think splitting it up would help.
Matsuhara: Does anyone know how to somehow trace the dependency tree such that I can do a gulp.watch on any files referenced by a main file?
Dilthey: I.e. if server.js happens to refer to ././blah/thing.js, then I would want to run a gulp task when thing.js changes
Marstaller: I think it’s complaining about so many if statements, because I use 4 if statements in another function and I get a complexity score of 13. Are there any alternative approaches to them?
Elvis: Marstaller: i seriously wouldnt worry about this. that sounds like not a very useful way to think about code
Marstaller: Tcsc: yes, I see what you mean. I was just thinking of it in case it gives me a new perspective on how I’m writing code with a view to improving it
Elvis: It seems like its a way of letting a computer guess how complex a piece of code is
Marstaller: Tcsc: thanks for your advice
Marstaller: Is there any information out there to advice which loop to use in different situations?
Spigutz: Marstaller: In general you should always use .map, .reduce or .forEach
Malm: Like my spelling abilities
Marstaller: What’s wrong with for i=0, ilen=errors.length; iilen; i++{. ?
Defusco: Tcsc: right, so you p*** in the entity object as ‘this’ which is ‘e’ in the contect of the function ‘collisionGrid.forEachEntityAround’, however, the function that’s p***ed in is within a different object so the value of ‘this’ changes, and as it’s not defined? within world.grid.forEachEntityAroundthis, functione it takes on the value of the global this, which is “window”
Budak: Ironically in #go-nuts people will tell you to just use for loops
Aburto: Marstaller: Its implementation specific
Goodhue: Marstaller: Its neater to use the array extension functions
Vallas: Marstaller: But you know, in practice you can do the same thing with eaier
Pouncy: For i=0, ilen=errors.length; iilen; i++{ const error = errorsi; .dostuff. }; vs errors.forEacherror = .dostuff.
Elvis: Inside CollisionGrid.prototype.forEachEntityAround the this value is the collision grid
Elvis: And then when we call the function p***ed in
Elvis: E.g. not as a method, and not with .call or .apply
Defusco: Yeah – but the function that’s p***ed isn’t within CollisionGrid.prototype.forEachEntityAround , so it isn’t the collision grid within that function.
Defusco: I think that makes sense, I’ve not learned enough for it not to ha
Defusco: If that makes sense , as in, I’m not really familiar with some strict OOP that might make that too counter intuitive
Terzian: Torkable: Sorry, I missed your comment from before. What’s wrong with forEach?
Elvis: Yeah this’s behavior isnt that weird
Parkers: Its just sorta useless
Dorrough: There is pretty much always a better abstraction
Elvis: I usually use for loops over foreach
Burbach: Torkable: Its useful for side-effects stuff, if you have to do that
Gerwig: I havn’t used a for loop or a forEach in close to a year
Alice: Torkable: What if you need to update some DOM elements based on an array or something like that?
Kalinoski: Meh, forEach is fine in my book
Suriel: Torkable: map is to transform the list into a new list, but some operations are just side effects
Royal: You *should* use forEach for side-effects, and map for transformations
Cherico: Map is for executing a function for each element in a list
Kalinoski: For loops are even better for mutation though
Kalinoski: If you wanna do the dirty work
Gunther: Usually the functions I work with return a promise