Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Refactoring: Simplify using refactoring from Dart #21

Open
tbosch opened this issue Mar 26, 2014 · 8 comments
Open

Refactoring: Simplify using refactoring from Dart #21

tbosch opened this issue Mar 26, 2014 · 8 comments
Assignees

Comments

@tbosch
Copy link
Contributor

tbosch commented Mar 26, 2014

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

@tbosch
Copy link
Contributor Author

tbosch commented Mar 26, 2014

Especially the changes to lib/change_detection/dirty_checking_change_detector.dart

@tbosch tbosch changed the title Simplify using refactoring from Dart Refactoring: Simplify using refactoring from Dart Mar 26, 2014
@caitp
Copy link
Contributor

caitp commented Mar 27, 2014

@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.

@caitp
Copy link
Contributor

caitp commented Mar 27, 2014

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.

@tbosch
Copy link
Contributor Author

tbosch commented May 2, 2014

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

@caitp
Copy link
Contributor

caitp commented May 2, 2014

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

@EisenbergEffect
Copy link
Contributor

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 [email protected]:

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

@caitp
Copy link
Contributor

caitp commented May 2, 2014

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

@tbosch
Copy link
Contributor Author

tbosch commented May 2, 2014

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants