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.
@mikeal
Copy link

mikeal commented Nov 2, 2011

it's also conceptually simpler to know that assignment always mean the same thing and that their behavior isn't in some abstract method somewhere. having all this customization is not without cost, the semantics need to be kept in your head whenever you're reading code and all of a sudden the simplest thing, property assignment, can mean a whole host of other things.

@mythz
Copy link

mythz commented Nov 2, 2011

@mikeal

The point of my example was to show the necessary code required to proxy your model with a UI element so that:

viewModel.firstName = "new name"; 

Can update the UI, or update the server, or anything else.

@tj
Copy link
Author

tj commented Nov 2, 2011

@mikeal yeah exactly, at least with method calls you're opting in to complexity

@tj
Copy link
Author

tj commented Nov 2, 2011

it's not even like it's more convenient really:

user.set('name', 'tj');
user.name('tj'); // if you know ahead of time via schema etc
user.name = 'tj';

not a huge deal

@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