The redux best practices says not to mix plain javascript object with immutablejs objects. I'm trying my hand at functional programming and it seems like the monads require the computations/values to be stored inside an object, or some container of sorts. AFAIK immutablejs maps can't store methods. Are there any issues with using FP libraries like Folktale? I haven't noticed any noticeable issues with the basic todo app (which is all I can try at the moment), so I'm hoping for some clarification on immutablejs best practices, hopefully FP leaning.
Never mix plain JavaScript objects with Immutable.JS
Ok, I feel like a fool. I read the linked article again and saw that it's not about performance, but to avoid confusion as to when data passed is immutable or a pojo. Here's the relevant section from the article
In fact, sometimes you might be tempted to put a normal JavaScript object inside an Immutable map. Don't do this. Mixing immutable and mutable state in the same object will reap confusion.
http://jlongster.com/Using-Immutable-Data-Structures-in-JavaScript
Related
I have been studying functional programming and one of the requirements is that they are pure in the sense that they only return the computed value and not touch anything else or throw exceptions, they don't also access shared mutable objects - this makes them inherently thread safe.
So then what would be the correct approach to implement a pure function that takes objects as arguments rather than primitive values. Would I have to deep clone them when passing to a function ?
If the function is a pure function, i.e. does not modify existing objects, whether they are passed as parameters or lying around somewhere else, there is no sense is copying or cloning the argument objects.
You could also see it the other way round: if cloning arguments is necessary, the invoked code is not functional and cloning the arguments doesn’t turn it into functional code, it’s actually working around a design flaw.
In the best case, you would be working with immutable objects which prevent modifications intrinsically, however, using immutable objects doesn’t change the way how the functional code should behave, they just enforce some aspects of it. When a particular class does not offer immutable objects, you can still use it in the right way, without the need to re-implement it in an immutable way.
Generally, it is not a good idea to develop your code assuming that all other code will misbehave and that it was your code’s task to solve the issues of that misbehavior.
The objects should ideally be immutable. Immutability and functional programming go hand-to-hand.
If having all immutable objects isn't feasible, yes, you would ideally need to make deep copies of everything to ensure changes to them don't effect anything else outside of the function.
Scala claims than OO and FP can be combined.
I wonder how this can be achieved in practice. I mean object can change, so making them immutable means i have to create a new object whenever something changes right? This doesn't seem too effective to me.
By the way, if i make external reference to an object property from a function, doesn't it hurts referential transparency?
Don't think of this as one paradigm imposing restrictions on the other but as how can one take the best of both paradigms.
As a simple example:
Objects have functions which can be internal to an object. Now the internal functions can be immutable within an object and those results of a function can be used to change the state of a object.
Thinking at a different level one can use functions to create a library that can be used by objects.
How I like to make the best of both is I tend to make libraries (modules) for the more abstract processing using a functional language and then use OO languages for the layers closer to human and external processing. This is not a hard and fast rule but a guideline from where I start.
I've been using Object as a way to have a generic associative array (map/dictionary) since AS3/Flex seems to be very limited in this regard. But I really don't like it coming from a C++/Java/C# background. Is there a better way, some standard class I've not come across... is this even considered good/bad in AS3?
Yes, Actionscript uses Object as a generic associative container and is considered the standard way of doing this.
There is also a Dictionary class available, flash.utils.Dictionary.
The difference is that Dictionary can use any value as a key, including objects, while Object uses string keys. For most uses, Object is preferred as it is faster and covers the majority of use cases.
You can see the details on Object here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Object.html
and Dictionary here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/Dictionary.html
and the differences between them here: http://livedocs.adobe.com/flex/3/html/help.html?content=10_Lists_of_data_4.html
I'm afraid there's no native alternative to Object or Dictionary for maps and other structures. As for standard, well, it depends on how one defines standard, but there are a couple of known libraries that you might like to check out if you look for Java style collections.
Like this one:
http://sibirjak.com/blog/collections/as3commons-collections/
Also, you could take a look at this question, that has links to a couple of ds libraries (including the above one).
Collections in Adobe Flex
I wouldn't say using Objects is either good or bad practice. In the general case they are faster than any Actionscript alternative (since they are native), but less featured. Sometimes the provided functionality is good enough. Sometimes, it's a bit bare-bones, so something more structured could help you getting rid of lower level details in your code and focusing in your "domain logic", so to speak.
In the end, all of these libraries implement their data structures through Objects, Dictionaries and Arrays (or Vectors). So, if the native objects are fine for your needs, I'd say go with them. On the other hand, if you find yourself basically re-writting, say, an ad-hoc Set, perhaps, using one of these libs would be a wise choice.
I was recently watching a webcast on Clojure. In it the presenter made a comment in the context of discussing the FP nature of Clojure which went something like (I hope I don't misrepresent him) "Mock objects are mocking you".
I also heard a similar comment a while back when I watched a webcast when Microsoft's Reactive Framework was starting to appear . It went something like "Mock objects are for those who don't know math")
Now I know that both comments are jokes/tongue-in-cheek etc etc (and probably badly paraphrased), but underlying them is obviously something conceptual which I don't understand as I haven't really made the shift to the FP paradigm.
So, I would be grateful if someone could explain whether FP does in fact render mocking redundant and if so how.
In pure FP you have referentially transparent functions that compute the same output every time you call them with the same input. All the state you need must therefore be explicitly passed in as parameters and out as function results, there are no stateful objects that are in some way "hidden behind" the function you call. This, however, is, what your mock objects usually do: simulate some external, hidden state or behavior that your subject under test relies on.
In other words:
OO: Your objects combine related state and behavior.
Pure FP: State is something you pass between functions that by themselves are stateless and only rely on other stateless functions.
I think the important thing to think about is the idea of using tests help you to structure your code. Mocks are really about deferring decisions you don't want to take now (and a widely misunderstood technique). Instead of object state, consider partial functions. You can write a function that takes defers part of its behaviour to a partial function that's passed in. In a unit test, that could be a fake implementation that lets you just focus on the code in hand. Later, you compose your new code with a real implementation to build the system.
Actually, when we were developing the idea of Mocks, I always thought of Mocks this way. The object part was incidental.
I'm relatively new to flash, and is confused about what I should use to store and retrieve key value pairs. After some googling I've found various map-like things to choose from:
1) Use a Object:
var map:Object = new Object();
map["key"] = "value";
The problem is that it seems to lack some very basic features. For example to even get the size of map I'd have to write a util method.
2) Use a Dictionary
What does this standard library class provide over the simple object? It seems silly for it to exist if it's functionally identical to Object.
3) Go download some custom HashMap/HashTable implementation from the web.
I've used a lot of modern languages, and this is the first time I haven't been able to find a library implementation of an associative array within 5 minutes. So I'd like to get some best-practice advice from an experienced flash developer.
Thanks!
Maybe your google foo is a bit weak today?
But you're right, the built-in Object object, doesn't provide many extra features.
Dictionaries have at least two important differences with Objects:
They can use any object as a key. For Objects, the key has to be a string (if you pass any other object, the toString() method will be implicitly called).
You can optionally set they keys to be weak referenced (this doesn't make much sense for Objects).
Anyway, there are a number of opensource libraries that implement various data structures and collection types.
Just from the top of my head:
http://lab.polygonal.de/ds/
http://sibirjak.com/blog/index.php/collections/as3commons-collections/
You should use whichever option is needed for a particular situation. There is no correct answer to say "always use 'x'".
I've found that the vast majority of times Object based dictionaries are all that's needed. They're extremely fast and easy to use and I almost never need the extra features. It converts any key to a string which works well for most situations.
Dictionary provides some extra features but I've never needed object-based keys (and I've been programming in Flex since 1.0 alpha 1). The only time I've used a Dictionary is as a hack to get access to a weak reference since Flex doesn't provide a simple weak reference class.
More complex dictionaries are available which will provide more functionality. If you really need this functionality, then they will be useful, but I wouldn't recommend jumping in to use them when a plain old Object will work find for your needs. That said, if you do turn out to need them in your application, it might be best to using the same 3rd-party dictionary everywhere in that app for consistency and easy of maintenance.