• Fristator (unregistered)

    An that's the frist thing about JS to dislike!

  • (nodebb)

    I can confirm, this would be a disaster in any language.

  • (nodebb) in reply to Mr. TA

    Ya, this JavaScript is not a frist

  • Randal L. Schwartz (google)

    In this case, no such thing as "event-ual consistency".

  • xtal256 (unregistered) in reply to Mr. TA

    Not one with a well designed event API (although I know of no such language, well maybe C#) that makes it obvious that you are adding an event handler for click or mouseover or somesuch and not simply replacing it. One might expect that $("something").click(doSomething) will set up doSomething to be the one and only handler of click events.

  • Kythyria (unregistered) in reply to xtal256

    The DOM itself makes that clearer, with the method jQuery is calling being addEventListener. Unless you were using the really ancient onXxx properties, I guess, but AFAIK setting those does replace what was there previously.

    So this is a secondary mini-WTF , that jQuery doesn't convey what the underlying API does.

  • NoLand (unregistered) in reply to Kythyria

    I guess, but AFAIK setting those does replace what was there previously.

    Can confirm, assigning to onXxx overwrites, addEventListeners adds.

    Moreover, adding the same listener for the same event twice, fires only once. BUT: This does not work wit anonymous functions for handlers, since these will have a different signature each time they are added. Here, it's really every Web Ninja's favorite weapon, which is to blame. For fail-safe coding, define a named handler and add this to the Event target as a listener.

  • 516052 (unregistered)

    The real WTF is that no language I know off has an event API that lets you clear all listener from a handler easily. Like yes, C# kind of has the handler = null thing. But let's be real. We need eventName.RemoveAllListeners().

  • (nodebb) in reply to 516052

    That would be a violation of the principle of separation of concerns. The calling site has no idea who else attached to that event.

  • David Mårtensson (unregistered)

    This is not only in JS, sure JS makes it easy to do but going back to when chrome was a new browser they had similar problems in C++.

    Their mapping of the JS event functions worked fine when you added new event handlers, but the code mapped for remove event handles linked to removed objects was not working, so a page that rewrite dom objects got slower and slower the longer the page was in memory until it just locked up.

    And I have seen it in C# to.

    The reasons it is more visible in JS is first that you do these kinds of things by your self more often, in other languages you usually use some ready build library for similar things.

    And JS is actually quite resilient to errors like this and that means its easier for such errors to survive through testing into production.

    In most other languages you would get more visible errors that would force you to fix them, but JS engines have been built to cope with fabulously bad code without going totally dead :P

  • 516052 (unregistered) in reply to Mr. TA

    How so?

    The way these things work is that you basically have a list of attached handlers and every time you trigger the event it goes through that list and pings everyone. So by definition the event handling site has to know everyone listening to its calls or else it wouldn't be able to send them a message when the event triggers. You can't escape from this sort of setup.

    So why not allow the ones calling the handler to also be able to clear it instead? As in inform everyone that the service is canceled.

    You could easily enough make it a compiler error for the thing to be cleared from outside the class that defined the event if SOC is your concern.

    Plus frankly I find it to be very bad for a language to obtusely limit my ability to work by removing good tools just because somebody might misuse them.

  • Ollie Jones (unregistered)

    "come from" considered harmful.

  • (nodebb) in reply to 516052

    Because now the caller is stomping over everyone else's event handlers whether they're still needed or not. Or be aware of which other callers are using event handlers so that it doesn't arbitrarily delete those that are still needed.

    If caller A set an event handler it's not up to totally unrelated caller B to clear it by calling a "cancel all event handlers" method, because now A's behaviour (namely, the consequences of whether or not it is notified of the event in question) is dependent on B's totally unrelated behaviour.

  • Officer Johnny Holzkopf (unregistered) in reply to Ollie Jones

    Please "go to" the clien parner to receive a less harmful consideration.

  • Arcplux (unregistered)
    Comment held for moderation.
  • 516052 (unregistered) in reply to Watson
    Comment held for moderation.

Leave a comment on “Quite the Event”

Log In or post as a guest

Replying to comment #:

« Return to Article