Shuga: Biddlecome: http://pastebin.com/zy2***sW

Friedberg: I’m using angular.extend in a similar way as _.extend

Igbal: Boar, start by making the rules thing its own function http://pastebin.com/dYZy4uMy

Ornelaz: Hm. so what’s the difference between subtyping and row polymorphism. is it just that one says that there are likely more fields?

Gedeon: Boar, and in what way does rules need to modify Product?

Ornelaz: Thats what my brief google of the subject seems to imply.

Manka: Biddlecome: It’s driven by a rule system more or less, namely I’ll be using Nools.js to run it

Dunning: Biddlecome: So it could change any number of things

Pedroso: You can model changes like this: http://pastebin.com/D2J8zTuy

Giguere: But if you have an object that can be modified arbitrarily from many different places it’s really hard to track down bugs, so objects should update themselves

Kazmierczak: Angular.extendproduct, toConvert; should be more like: angular.extendproduct, {description: toConvert.description}; so you can explicitly see which properties are being mutated

Evett: Tcsc: in subtyping you have a relationship of subsets: a : b means that b is at least a, but contains something more. Its differences aren’t captured in the type, just the relationship. With row polymorphism, you capture, instead, the difference in types, and can construct new types by combining these differences. So { a b: c } – { a b: d } is

Sligar: A type that takes an input containing an object that has at least b: c, keys, and returns a type that contains a b: d key, alongside whatever else the input type had which is captured by the row variable a.

Loftis: It’s relatively easy for a HM-style algorithm to infer the types in a row polymorphic type system. You just put whatever the person access in the requirements the things after the , and capture everything else in the row variable.

Ehl: Loading a CommonJS module should never have a side effect right?

Ornelaz: I see, that’s what you meant by inference. globally thats not something i think helps program understandability tbh.

Chiquito: Biddlecome: Thanks Green, one of the limitations I’m having is that “Product” needs to be a typed object for the rules engine to work correctly, which is why I had it like that

Fegurgur: Tcsc: it isn’t. Global inference is more of a “convenience,” which is very interesting to have when you’re prototyping things.

Gatz: When you settle on the types you want, it’s important to go and put those on the source code so the next person knows what the constraints are

Ornelaz: So, if you don’t need to construct a new instance of the type, then row polymorphism doesn’t have a benefit over subtyping?

Gerken: Tcsc: well, if you’re not accepting subsets of a type, then there isn’t any use for either row polymorphism or subtyping

Ornelaz: Frequently you accept a subset of a type, but don’t use anything but that subset

Meneus: BigJono: yeah, side effects when loading a module is a no-no unless you’re doing something very specific like monkeypatching your environment

Meneus: Which, unless you’re shimming, is probably also a bad idea, or should at least have a high burden of proof that you need it

Emal: BigJono: modules in general shouldn’t have side-effects. They’re just objects that implement a particular interface. Things like require’es5-shim’ are not really modules, just loading programs.

Meneus: The other big exception, other than shimming, is for require hooks like you see in babel and typescript

Meneus: But that’s more of a loading program as well

Renison: I’m getting an error with Highcharts, saying it’s been defined twice global namespace clash or somesuch. Wouldn’t that be literally impossible if I’m only ever loading it using browserify’s require?

Vasey: Meneus: doesn’t help that “module” has very inconsistent definitions everywhere :/

Sastre: BigJono: well, if you require it in two modules, you’re loading it twice.

Meneus: That should still not cause problems unless highcharts itself is polluting the global namespace though