On 8/9/16, 8:59 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>BTW: > >If we look at getting rid of goog.events, we might want to look at >getting rid of goog.inherits and goog.base as well. IMO, goog.events is separate from goog.inherits and goog.base. Erik would know best, but I think the GCC optimizer understands goog.inherits and goog.base. It doesn't care about goog.events. Someone is welcome to write an emitter that uses different amounts of goog. > >On Aug 9, 2016, at 6:39 PM, Harbs <harbs.li...@gmail.com> wrote: > >> You do get an error, but the error loses the stack. All you have is the >>function which threw the event, but you have no trace of the object >>which handled the event (and caused the error). Actually, in reading up on JS error, I don't think there is a getStackTrace() call. What happens if you set a break point on that catch line? Would that be a useful best practice when debugging or just too painful? >> >> I have no idea why this is so. I assume it has to do with “callback >>hell” and the callbacks which the event system uses. >> >> If we do redo the event system we might want to use Promises instead. I didn't think Promises had anything to do with events. >> >> I’d like to get to the point where we can merge the sprite-refactor >>branch back into develop before we start fixing other things, though… ;-) I'm tempted to cut a release before we merge in sprite-refactor. Peter is looking into the examples now, but I think there is going to be a fair amount of debugging to be done. Or do you think the code-intelligence changes are really going to be a huge improvement to folks? -Alex
