Le 28/11/2012 14:47, Marius Gundersen a écrit :
On Wed, Nov 28, 2012 at 1:21 PM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
Hi Marius,
I won't say the idea is bad, but what would be the benefit of this
new type of function?
From experience on this list, if a new idea cannot prove to make a
major difference with what currently exists, it is not considered
to be added to the ES6 spec.
The major difference can be in performance, security, language
extensibility, programming idioms/conveniences, etc.
Do you have reasons to think pure functions as you propose them
make that big of an improvement as opposed to JS as it is?
With many new functional programming possibilities (like map, reduce,
filter, lambdas) there are many scenarios where the implementer should
use pure (or as I renamed it in another reply, side-effect-free)
functions.
Why "should"? What is the problem if people don't?
Library implementers are likely interested in making functions that
can take lambdas as parameters, and these lambdas (in many cases)
should not alter any outside state, they should only return a value. A
function with this restriction could run faster and take up less
memory since it only needs the values passed to it as arguments in its
own scope.
"could run faster and take up less memory". I agree it "could", but it's
not given it will when implemented. In some cases, it's possible to
prove that a function is side-effect free, but to the best of my
knowledge, no implementations has gone to length to do such thing,
probably, because the cost is too big in regard to the benefits.
Mostly I feel this would introduce better coding practises with a
focus on functional programming rather than object oriented programming.
I'm only half sympathic to this argument. JS is a language with many
users with different programming styles. I understand the benefits of
FP, but don't see why it should be favored over any other style.
Using functions with limited scope would reduce the number of
variables written to the global scope
I use both OOP and FP styles and I don't see how FP would help for
global variables. Basically, declaring variables as function local (with
the "var" keyword) prevent global leaks.
and would reduce the amount of state in an application.
...and increase the use of temporary values and GC to compensate,
because JS engines are not really written to optimize for FP? For
instance, I think, none do tail call optimization yet? (others in the
list know better on that point)
Seeing as FP is a bit of a trend today (due, in part, to the
popularity of JavaScript), it seems to me like a good idea to
implementing features which help promote good FP patterns in a
language that allows for both FP and OOP.
You mentioned ReferenceError when the functions tries to reach a
variable outside of its scope. I think it's possible to implement such a
thing in current JavaScript. Take a look at the Caja code [1] for
inspiration (sorry the barrier is a bit high as I put it. Ask me
questions if you need help).
Also, to avoid being tempted to use a scope, just define your function
as non-nested (global :-s or directly inside an IIFE (Immediately
Invoked Function Expression))
Just a note:
function@ f(x){
x.a = 1;
}
I think this is a side-effect. Should an error be thrown here too?
If so, does it mean you can't use objects as arguments?
In any case, none of what you answered really convinces me (just to
clarify, I just hang out on the list, I make no decisions with regard to
the language) as being a major improvement for the language. It would be
a good convenience for FP style, that's it.
David
[1]
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#635
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
