flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: FlexJS stopImmediatePropagation
Date Tue, 09 Aug 2016 16:28:04 GMT

On 8/9/16, 8:59 AM, "Harbs" <harbs.lists@gmail.com> wrote:

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

>> 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?


View raw message