
Jeremy Ashkenas's proposal for minimalist JS classes  - akavlie
https://gist.github.com/1329619
======
jonmc12
Much more concise. I was curious on Jeremy's view on getters, setters in JS -
can be summed up as it is "impossible to reason about the side-effects of your
code" (aside from the fact that it also does not work on IE).

<http://irclogger.com/.coffeescript/2011-01-05#1294280074>

How is that different than the validation / error handling in the model set
method in Backbone.js (in that they can run arbitrary code)? Is it just the
distinction of side-effects in the language vs the framework?

Also, why should a = obj.b need to be any more predicable than a = obj.b()?

It seems like there are benefits to using getters / setters (ie,
<http://ejohn.org/blog/javascript-getters-and-setters/>), and I actually think
the syntax is cleaner "get firstName" vs "getFirstName". Curious to understand
more about the objection.

~~~
tolmasky
It's simply interesting that this:

    
    
      for (key in hash)
          hash[key] = null;
    

May or may not call a bunch of functions. It could turn out to be a debugging
nightmare.

~~~
skrebbel
There are many popular languages for which this is the case (C#, Ruby, PHP
even), and I haven't heard anyone panic yet.

The deal is that if you implement a property getter, you promise no side
effects and fast execution (for some value of "fast"). If you don't do this,
your code is broken.

------
jashkenas
You can jump into the thread (or read back up the list for context) on ES-
Discuss, if you're in the mood: [https://mail.mozilla.org/pipermail/es-
discuss/2011-October/t...](https://mail.mozilla.org/pipermail/es-
discuss/2011-October/thread.html#17793)

~~~
colin_jack
Out of interest do you see a noticable increase in the will to actually
improve JavaScript?

------
apparatchik
Are Github's comment contrast or color adjustable? They are almost completely
unreadable for me.

~~~
jashkenas
Nope, but perhaps the "raw" view will help:
[https://raw.github.com/gist/1329619/6739dd2eb9f1cf91ecca27aa...](https://raw.github.com/gist/1329619/6739dd2eb9f1cf91ecca27aaa0d53a837ab40c91/minimalist-
classes.js)

~~~
apparatchik
Yes, this is what I ended up doing and reading it in my editor.

------
jwallaceparker
I agree completely. I hope this article has legs.

------
ilaksh
I don't understand why we are still using JavaScript at all now that we have
CoffeeScript.

Seriously, can someone please explain this to me?

~~~
billybob
If you mean "why isn't everyone coding in CoffeeScript and compiling to
Javascript," the answer is that not everyone sees the benefit in learning a
new syntax to write code they already know how to write in Javascript.
"Prettier code" isn't compelling for everyone, and adding a layer of
abstraction can generate its own problems.

You still have to debug your Coffeescript in Javascript, so you still have to
understand Javascript. Unlike, say, HAML, where you can't possibly do anything
in HAML that you wouldn't know how to do in HTML, Coffeescript lets you avoid
learning about JS prototypes by using Coffeescript classes and letting it
translate for you. You'd better hope the abstraction doesn't leak.

I'm not against Coffeescript - I'm excited to start using it soon. I'm just
saying that I understand why not everyone is.

If you mean "why do we still have to compile to Javascript," well, we'll have
to do that at LEAST until every browser supports Coffeescript natively
(currently none do, so you're looking at maybe 2025 when IE9 falls out of
use), and probably beyond that (since there's little chance that MS will break
backwards compatability with JS).

~~~
billybob
Another reason might be toolchain. If you're coding in a Rails 3.1
application, Rails takes care of compiling your Coffeescript and SASS and such
for you. If you're using a toolchain that doesn't do that for you, you have to
set up watch scripts and decide where source and compilation go, etc etc. That
headache has to be weighed against the perceived benefits.

