angular/watchtower.js

Refactoring: Simplify using refactoring from Dart

Opened this issue · 8 comments

The Dart code for dirty checking has been simplified, and porting those changes would make the JS code simpler as well.

See this SHA: mhevery/angular.dart@e12e5b5

Especially the changes to lib/change_detection/dirty_checking_change_detector.dart

@tbosch this patch isn't really simplifying things, it's just re-organizing stuff (particularly the change to the dirty checking code). None of this is actually "simpler" in dart either, but in JS-land none of it is really applicable.

We don't need to anything really special to create a "field getter", although sometimes those are wrapped in a new Function() ... (which is potentially a problem for CSP, but ignoring that...) --- there's no real distinction between a static field and a non-static field, they just refer to different objects... I don't think there's anything particularly compelling in this commit that needs to be pulled in, it just generally doesn't make sense for JS. Basically since we don't have "real" introspection in the first place in JS, and data is a lot simpler, most of this is just completely irrelevant there.

I do think there is no shortage of cargo-cult to be removed, though, that is definitely true. But re-arranging where getters are created doesn't really accomplish much, IMO.

Ok, can we do the following:

  • remove the unneeded modes in dirty_checking.js, as they are only meaningful in Dart context: _MODE_GETTER_,_MODE_MAP_,_MODE_REFLECT_
  • go through the code and resolve all TODOs that are related to the porting
    • e.g. add traceur annotations,
    • e.g. delete change_detection.js as ES6 does not support traits
    • e.g. remove getters/setters where plain properties are enough

I think we probably do want _MODE_MAP_ for easy access to Map objects, but maybe keeping it simple is better for now

Actually, can you keep change_detection.js for now please ;) I need to use
that as a blueprint for the O.o integration. Thanks!

On Fri, May 2, 2014 at 3:18 PM, Caitlin Potter notifications@github.comwrote:

I think we probably do want MODE_MAP for easy access to Map objects,
but maybe keeping it simple is better for now


Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-42068025
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

I guess since we don't get any of the static-typing benefits of dart, actually, special casing all of that stuff is probably a mistake because it's always dynamic

@caitp I would vote for keeping it simple, as reading a map would always be done via a method call. So lets remove it.