ease.js - Tasks: task #12088, Initial Refactoring: Prototypes...
You are not allowed to post comments on this tracker with your current authentication level.
task #12088: Initial Refactoring: Prototypes and Composition
Submitter: | Mike Gerwitz <mikegerwitz> | ||
Submitted: | Sat 09 Jun 2012 11:44:41 PM UTC | ||
Should Start On: | Fri 26 Aug 2011 04:00:00 AM UTC | Should be Finished on: | Tue 01 Jan 2013 05:00:00 AM UTC |
Category: | Core | Priority: | 9 - Immediate |
Item Group: | Maintenance | Status: | In Progress |
Privacy: | Public | Assigned to: | mikegerwitz |
Percent Complete: | 40% | Open/Closed: | Open |
Planned Release: | None | ||
Keywords: | refactor |
No files currently attached
Depends on the following items
Items that depend on this one
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2012-06-10 | mikegerwitz | Dependencies | - | task #12092 is dependent | |
2012-06-10 | mikegerwitz | Dependencies | - | Depends on task #12091 | |
2012-06-09 | mikegerwitz | Dependencies | - | Depends on task #12089 |
Powered by Savane 3.13-caa5.
Corresponding source code
Initially, ease.js was "a basic collection of CommonJS modules" that provided a small framework for classical OO. Not anymore. The project itself has grown to the point where it would benefit from itself. Unfortunately, that's not feasible, so let's fall back on applying my object-oriented practices to prototypes.
ease.js currently adopts a very basic modular design, in the sense that each module is an object and collection of functions that essentially acts as a singleton. Unfortunately, this has a number of important consequences: it's becoming difficult to cleanly abstract the code and it has always been difficult to test in units.
This refactoring, while it's been necessary for a while, stems from more complicated fallback logic emerging from the hidden method implementation. Ideally, this logic should be entirely separate from the "normal" logic, which would be best handled by composition. Unfortunately, composition is not very clean when dealing with singleton-like objects. As such, dealing with instances seems more appropriate and would provide additional testing benefits. There shouldn't be much overhead with instantiation, especially considering all the crazy stuff ease.js currently does.
This shift will be gradual. It will also help resolve the irony that the OO framework's code base doesn't demonstrate very many OO concepts in itself.
The tests are also getting a bit of an overhaul in this refactoring. They are currently acting more as integration tests rather than unit tests. This evolved out of difficulties with testing the basic modular design that was initially intended for performance on older browsers. Since this optimization is highly premature and the complexity has far outweighed the benefits (as clearly mentioned above), the subsequent refactoring will allow for proper unit testing.
These tests will be refactored as needed.