I am using a cffi-powered wrapper library cffi and there are objects to clean up. I am wondering if I can forego the need to write the clean-up code (or mitigate the use of with-smth macros) by encapusalating such objects in classes with destructors. Can I do that?
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.
There are probably several ways to implement this introspection feature through macros and code walkers, but is there a simpler (possible, implementation-dependent) way? I'd imagine, invoking and then releasing the debugger could open access to frame stack, but that seems like an overkill too.
What would be some simpler ideas to try?
Macros can take an &env argument that passes in the lexical environment of the calling context. You can then query the lexical environment using these functions: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html
In particular, check out variable-information and function-information.
I believe there are also implementation-specific ways to get the current lexical environment at run-time.
JS libraries like Underscore.js and LoDash.js provide functions, usually via a global object _:
_.map(...);
_.filter(...);
Such basic functions are global functions in Python and part of the standard library:
map(...)
filter(...)
If I promoted the library functions to global functions...
window.map = _.map;
window.filter = _.filter;
map(...);
filter(...);
... what downsides would there be (other than global namespace pollution)?
Do I have to expect any performance issues?
Will it lead to errors in certain browsers? (e.g. if a built-in JS function is overwritten by a library function, which in turn relies on the native function)
Will chaining still work?
There are multiple downsides, but performance is not likely to be one of them.
What if two libraries have a map() function and the behaviors are slightly different? If they both put their map() in the global space, you won't be able to access one of them. And you might not be able to easily know that the map() you actually want has been overwritten.
By the way, map() and filter() are part of recent-ish JS implementations, but even there, they are part of the prototype of the objects that use them. So you have Array.prototype.map() and Array.prototype.filter().
Here are some reasons to avoid making lots of things like map and filter be global variables:
Naming conflicts with other code/libraries attempting to do something similar, but incompatible. If all code is using numerous global functions, then the simple definition of a single global function could completely break your app because it would be redefining such a function used for something else somewhere else in the code. This, all by itself, is a reason to use as few globals as possible. In a team project or a project using significant third party libraries, this is impossible to manage and will inevitably lead to lost productivity or, even worse, bad bugs that might not immediately be apparent.
Code modules are less self describing when a symbol is just global. Hmmm, where does the symbol map() come from. Is this built in? Is it defined locally? Is it defined by some library? It's a lot easier to know where gutils.map() comes from (from the gutils module). Large numbers of global anything is just less maintainable than breaking things into well defined modules.
There are numerous advantages to defining functions as methods on the objects on which they operate (such as ES5 .map() and .filter() being methods on the Array object rather than as generic globals). Now, it is considered bad practice to add non-standard methods to existing built-in objects (also for naming collision reasons), but adding polyfills that implement standard behavior is encouraged.
See these references for other info:
How and Why to Avoid Globals in Javascript
I've Heard Global Variables Are Bad, What Alternative Solution Should I Use?
Essential Javascript Namespacing Patterns
Javascript Namespaces and Modules
How do I declare a namespace in JavaScript?
As to the topic of performance, it should not be your first concern and will likely not even be a relevant concern in most code. It is much more important to start with a robust, maintainable coding strategy and then optimize only small pieces of code where performance is critical than to sacrifice robustness at the beginning in the name of performance.
In any tight loop where performance is criticial, you can always assign any function to a local variable to slightly improve performance and this will be faster than either a module reference or a global reference (because locals are resolved before globals).
So, if you had gUtils.map() in a module and you want to maximize performance inside a particular function, you can do this:
function x() {
var map = gUtils.map;
for (var i = 0; i < someBigNumber; i++) {
map(...);
}
}
Consider a library like this,
_ = (function(){
lib = {};
lib.function1 = function(){
//code
};
lib.function2 = function(){
this.function1();
};
//more code
return lib;
})();
if you use,
window.function2 = _.function2;
function2();
The library uses "this" operator in function2. Your way changes the scope of the function2 here. The function2() call will give an error saying "function1 is not defined".
You don't need to worry about performance; even if you add an extra layer to a symbol lookup, most modern JS engines will alias it. Nor should you worry about augmenting native objects causing exceptions - that's allowed. No, the big issue is the namespace pollution, which you seem to be a bit dismissive of.
What happens when your code runs on a newer browser that implements these functions natively? Let's say you'd written this code in 2009, and added .map() to Array.prototype. Your code would now have some big issues if someone added a new library that expected one function signature (the native one's) and got a different one (yours).
If you must do this, at least check whether the global symbol already exists, e.g.
window.map = window.map || myLib.map;
Also, make sure that any code relying on your map implementation can either signal its dependencies to a JavaScript dependency management tool like RequireJS, or that you have a robust DM system already in place, and that your native overrides are attached before any other code executes (e.g., don't put your code in an async script tag, don't defer execution until DOMContentLoaded, etc.)
Is it a way to create mutable state with modules? How can using this be a good idea? Wouldn't that kind of break the immutability idea from functional programming?
No because it's used at compile-time. It's kind of #define in C.
You can see example https://gist.github.com/mprymek/8379066 where attribute "sensors" is used to accumulate functions defined with macro "sensor". When you have all these functions accumulated, you can automatically generate function "run_all" which runs all of them. Of course all of this must be done at compile-time.
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.