Skip to content

Instantly share code, notes, and snippets.

@tj
Created November 2, 2011 20:13
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tj/1334751 to your computer and use it in GitHub Desktop.
Save tj/1334751 to your computer and use it in GitHub Desktop.
@mythz
Copy link

mythz commented Nov 2, 2011

Except no one expects user.name to be a function.

@paulmillr
Copy link

Here's an example of Proxies awesomeness: Clojure-like contracts, http://disnetdev.com/contracts.coffee/. In production mode, you can just disable proxies without neediness to rewrite the code, so contracts overhead wouldn't affect users.

@tj
Copy link
Author

tj commented Nov 4, 2011

that's a reasonable use-case I guess. The fact that you kinda have to use js in the browser makes that ok, but that's not the language js is... otherwise you can just have your pick of functional/strictly-typed languages. The fact that you would have to compile that to js first to achieve the functionality is even worse, at that point you might as well just make it a transpiler feature that you can toggle on and off

@andreyvit
Copy link

@visionmedia What makes the language better for your use cases (and aesthetic sense, which I must add I highly respect) isn't the same thing as what makes the language better for the popular and important use cases. You don't have to use getters or proxies if you don't want to, but I'm surprised that you cannot see why some other peoples' code would be improved by using them.

  1. If magic get/set is the prevalent library abstraction you use, there's really no possible confusion about assignment semantics. Imagine most property assignments in your code being function calls instead; that's losing a lot of clarity without adding any knowledge. When working in a reactive environment, a magic get and a magic set are the normal behavior of every property assignment
  2. That's not some niche use case. People are building stuff like reactive environments and data binding in JavaScript today, taking it to the places it has never been before, and we have no idea what will be popular tomorrow. We want to support that, rather than discourage that.
  3. Most importantly, the argument you're making is essentially counter to the idea of writing code in terms of interfaces, not implementations. Sometimes the distinction between .name and .name() is an implementation detail that should be hidden to allow proper duck typing. Should a function called max really care if it's operating on a real array or a reactive array class? While it's possible to over-abstract things, the right amount of abstraction isn't always no abstraction.
  4. Then there's an issue of being able to make changes. One day your person.name is just a property, the next day you want it to be reactive, so it has to become person.name(). Using different syntax to access immutable and mutable properties is crazy, you'd have to either always use person.get('name') just in case, or remember if name is mutable or immutable today. I'm all for refactoring and find-and-replace, but this particular trivial change feels like a stupid chore and gets annoying fast.
  5. And there's evidence of existing demand and of people applying ugly workarounds. Isn't that the best indication that a language feature is desirable? (Honest question.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment