Trine – A utility library for functional programming in JavaScript

Post by implicit » Thu, Jun 11, 2015, 4:36 PM UTC

codecurve wrote: post #61

the_mitsuhiko wrote: post #33

> They're both (subjectively) wrong: the natural place for data in JS is the this parameter. ... said the person not understanding the language semantics. Passing arbitrary data as this is a terrible idea. It has to be an object and as such all primitives end up boxed.

(function double() { return this * 2; }).call(2) === 4 I didn't have to box anything to pass a primitive as this. Maybe some other versions are different, but this works in Chrome 40 and Firefox 33.

    > function isboxed() { return this instanceof Number; }
    > isboxed.call(5);
    true

Post by vkjv » Thu, Jun 11, 2015, 4:40 PM UTC

striking wrote: post #52

bshimmin wrote: post #24

About halfway through the README, after some examples of the new bind syntax, it says "But why stop there?" Actually, please can we stop here? Just for a bit? This continual, persistent mangling of JavaScript's syntax really is starting to hurt. It's one thing to have to keep on top of the new frameworks springing up every five minutes - which you can, for the most part, ignore for at least six months until they star…

I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…

  function Person() {
  	this.age = 0;
  	setInterval(this.incAge, 1000, this);
  }
  Person.prototype.incAge = function personIncAge(that) {
  	that.age += 1;
  };

Post by loganfsmyth » Thu, Jun 11, 2015, 4:53 PM UTC

quinnirill wrote: post #8

loganfsmyth wrote: post #5

Looks cool. Not sure I get why installing `babel-runtime` would be something you'd have as a separate install step though, since there is no guarantee that the user would install the right version.

This is to avoid multiple versions of Trine required by libraries (or the application itself requiring a different version of babel-runtime) causing the different versions of `babel-runtime` to be included multiple times, which would be a problem especially for browser applications. Trine itself is very small, but if each module introduces a dependency to babel-runtime, it would be another case of "npm downloads the…

Post by icebraining » Thu, Jun 11, 2015, 5:00 PM UTC

CrossEye wrote: post #76

icebraining wrote: post #67

Earlier quoted context omitted.

Seems like you could just do var process = items => items.filter(isOk).map(toOtherType).flatten()

The difference starts to show when you want to partially apply some values. // process1 :: (Item -> Bool) -> [Item] -> [OtherType] // process2 :: [Item] -> [OtherType] process1(isOk, items); //=> [otherType1, otherType2, ...] process2(items); //=> [otherType1, otherType2, ...] var processR1 = seq(filter, map(toOtherType), flatten); var processR2 = processR1(isOk); var processT1 = (isOk, items) => items.filter(isOk).m…

  var processT1 = (isOk, items) => items.filter(isOk).map(toOtherType).flatten();
  var processT2 = partial(processT1, isOk);

Post by CrossEye » Thu, Jun 11, 2015, 5:21 PM UTC

wwweston wrote: post #80

bshimmin wrote: post #59

Earlier quoted context omitted.

My objections are around the rate of change and the fact that JavaScript is growing into a large, complex language that people are becoming really uncertain how to use.

JavaScript has always been a language people were uncertain how to use. The only difference with ES6+ is that the uncertainty will come from the addition of features people have complained were missing, instead of the traditional uncertainty that came from the intersection of its flexibility and dev's desire not to learn it.