ease.js - Tasks: task #12105, Events
You are not allowed to post comments on this tracker with your current authentication level.
task #12105: Events
Submitter: | Mike Gerwitz <mikegerwitz> | ||
Submitted: | Sun 10 Jun 2012 03:53:45 AM UTC | ||
Should Start On: | Sun 01 Jan 2012 05:00:00 AM UTC | Should be Finished on: | Sat 15 Feb 2014 05:00:00 AM UTC |
Category: | Core | Priority: | 5 - Normal |
Item Group: | Development | Status: | None |
Privacy: | Public | Assigned to: | mikegerwitz |
Percent Complete: | 0% | Open/Closed: | Open |
Planned Release: | None | ||
Keywords: | events, aspects |
Mon 11 Jun 2012 06:52:58 PM UTC, comment #1: [Additional Information] |
Mike Gerwitz <mikegerwitz> |
Sun 10 Jun 2012 03:53:45 AM UTC, original submission:
Permit event definitions for classes. This will permit visibility, inheritance, parameter compatibility, typing, etc - everything you'd get with any other members. It also provides a client-side implementation of events. Most importantly, it will prevent binding to events that have not been defined, which could be the source of unnecessary bugs.
|
Mike Gerwitz <mikegerwitz> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-05-20 | mikegerwitz | Planned Release | 0.2.0 | None | |
2014-01-20 | mikegerwitz | Should be Finished on | 2013-03-01 | 2014-02-15 | |
Planned Release | None | 0.2.0 | |||
2012-06-11 | mikegerwitz | Keywords | events | events, aspects |
Powered by Savane 3.13-d3ae.
Corresponding source code
Another consideration is one similar to aspect-oriented programming. Remember that one of the goals of ease.js is to reduce boilerplate code as much as possible. Consider, then, what might happen if a user decides to provide a flexible event API for a given class: possibly an event for each and every public method (if not more).
We can help to reduce this unnecessary code by allowing public methods themselves to act as events (perhaps a pre- and post- hook). Private and protected methods could also be hooked if they are in context.
Of course, this may not always be desirable; for example, someone wishing to have a final class may be upset to learn that the functionality of their class could still be influenced by aspect-like events. Therefore, we could need to provide a means to prevent this behavior. Whether this new behavior would be implicit or explicit has yet to be decided; the latter would obviously allow classes to work as expected by default, but the former would aid in creating easily extensible classes.
That said, this is a similar concept to the virtual discussion. Events are callbacks; they must be carefully considered/designed. This is still the case here. In that sense, perhaps the 'virtual' keyword could have additional meaning --- allowing it to be hooked. Then again, the developer may not want this, so that may not be the solution.
A separate keyword is an option.
Food for thought.