4 ms·
well you see! What we can do is to namespace our functions, e.g. by naming them component_create, component_add_button, etc. We then create a plain dictionary w
by heywhatupboys 3y ago
well you see! What we can do is to namespace our functions, e.g. by naming them component_create, component_add_button, etc. We then create a plain dictionary with key value pairs that gets passed onto these functions! The functions then possibly return a new map, which is a modified map! This allows us to write code like
dog = dog_create({name: "foo", age: 12})
dog = dod_add_friend(dog2)
print(dog["friends"])
and we can avoid OO completely.
oh... wait a minute
- epgui 3y agoThis comment shows a total misunderstanding of what functional programming is…
- heywhatupboys 3y agoWhile tongue in cheek, this is one if the OP in non-OP patterns that is used heavily for large projects in FP alike.
- epgui 3y agoI'm not seeing that in the example, and I'm not even seeing anything very relevant to FP in the example either. I guess there isn't much mutation happening, and functions are called? But that's not what FP is.
- tigershark 3y agoThis tells me that you never really looked at functional languages, not even used them. The power of ADT, especially when using a comprehensive pattern matching expression, is pretty difficult to emulate in the OOP world without a ton of code. But in this extremely simple case you just need a record. let dogBar = {Name = “bar”; Age = 11; Friends = []} let dogFoo = {Name = “foo”; Age = 12; Friends = [dogBar]} printfn “%A” dogFoo.Friends The advantage is that it’s immutable and it’s guaranteed to don’t have null in any fields. C# only introduced records recently, while F# was born with them. And C# still hasn’t got ADT because it’s missing the Union types as far as I remember.