• 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.

  • 516052 (unregistered) in reply to Watson

    I still fail to see how that is a concern for the people making the programing language as opposed to being a rare a powerful tool for developers to carefully and sparingly use. You sound like one of those people that originally made Java. Let's tie the developers hands behind his back and shove it up his arse so high he can't possibly do anything dangerous.

  • (nodebb) in reply to 516052

    Yes that's the better overall approach. It's how C# was (at least initially) designed, too. Somebody else mentioned it in the comments here, it's called "pit of success". The language and framework should be designed to make it difficult to make mistakes and make it easy to write good code.

    If you have the event publisher X, and 2 event subscribers A and B, and A subscribes to X, and B tells X to detach all subscribers including A, it breaks the functionality of A. B should be able to unsubscribe and resubscribe itself all it wants, but it can't control how X and A interact.

    If there is ever a need for B to tell X to detach all handlers, there must have been an architectural mistake which led to that situation. It's time to unwind and find that mistake. Think about it like a puzzle, if the corner piece doesn't fit and you know it's location 100%, then it must be adjacent pieces that are misplaced. Instructing unrelated classes how to communicate using events is an unfitting piece.

  • (nodebb) in reply to Mr. TA

    That's why jigsaw puzzles should include a pair of scissors. As a rare and powerful tool for making pieces fit.

  • 516052 (unregistered) in reply to Mr. TA

    And what if that "mistake" is legacy code and design you can't unwind? All this talk is fine in an academic setting but we live and work in the real world. And in the real world we need tools that let us do the things we need to do and not tools that pertend to be smarter than the user and curtail our ability to work.

    That's why I'll take raw C++ over Java any day.

  • (nodebb) in reply to 516052

    Absolute worst case, in .NET you can hack your way into doing that using reflection, so it's not a 100% lost cause. I'm sure Java is the same - you can hack into it. But, but, PLEASE do not do this ever. Use it to beat the management into approving an improvement to fix the underlying cause. Not a full rewrite - never do full rewrites - but targeted improvement to fix that particular situation. A fix a day keeps bugs and rewrites away.

  • 516052 (unregistered) in reply to Mr. TA

    And what if there is no way to fix it without a full rewrite of a system, half of which you don't actually own or have the code to? That is in fact the case where I am currently employed.

  • (nodebb) in reply to 516052

    I highly doubt there is ever such a thing as software which cannot be fixed and needs to be rewritten. All programmers are biased towards "let's rewrite it!" and one needs to force himself into thinking a different way. Even if the future perfect goal is a system which resembles nothing like the current system, small incremental steps should be taken to achieve that goal.

    WRT not owning or controlling the code, that's a whole different ball game. I'm talking about how to manage software that you're developing. If you have 3rd party crap which you have to make work somehow, it's not really a programming job anymore, more of a systems integration job (which involves some programming). In those cases, do whatever has to be done, charge the highest possible amount, and enjoy some whiskey in the evenings to forget the crap you deal with daytime, or connect with your spiritual side to find inner peace, whatever works.

  • 516052 (unregistered) in reply to Mr. TA

    If you think only real programming is working from scratch without any annoying and nasty dependancies you are as naive as they get. That or you are fresh out of school.

    You always have 3rd party crap you have to make work. Even if it's juts windows or importing libraries. Nobody programs from scratch any more. In fact its debatable if we ever did given that before Fortran and C compilers (which are 3rd party crap you have to make work) you had to know your hardware and make that crap work. And if you think crap needs making work today you should have tried in back in my day.

    Anyway, let's not get me started on stories from before half of you were born. Suffice to say that in my case it's simply a matter of having a specialized platform with which all our custom software must communicate. And it must do so via events. And events are the C# equivalent of function pointers. If you allocate one too many they behave oddly. Attach too many to the same event and it just drops some seemingly at random. Oh, and that's assuming you don't overflow the stack first when the event triggers. Because of course you can do that.

    And the platform is not owned by my team and is used by all teams so we can't just request changes either.

  • (nodebb) in reply to 516052

    I'm going to leave personal insults aside.

    OK so it sounds like you have a custom-made "platform" which is maintained by a separate team and it has many bugs around events. Again, there must be management at some high-enough level who can decide that the platform needs improvements. It's partially CYA but in a good way. If you raise these issues up the chain, the ball is in their court. If on the other hand you go off yourself detaching events which can potentially impact other people's code, you create a liability for yourself.

    In situations where you have limited control, you also have limited responsibility. This allows you to redirect the demand to the appropriate party. In situations where you have responsibility, you also have control - and that allows you fix the underlying problem.

    But there is never a good reason to cut the puzzle piece to make it fit.

  • 516052 (unregistered) in reply to Mr. TA

    Mistake not my intentions, no insult was intended. I was just pointing out that you either have a lack of experiance or some very odd and alien life experiances if you think the things you say. And you've done nothing to disuade me of that.

    For one, just because you have limited control absolutely does not mean you also have limited responsibility. Quite the opposite in fact. Managment does not care about technical details they don't understand. The best you'll ever get from them is "It works for everyone else. So stop complaining and do your job." Only worded in managment garbage talk that makes it sound all polite and nice. At least that's been my experiance for decades now.

    Secondly, there is no way in hell you can ever get a big company to have the core team that controls the inner platform the entire company works on rewritten or radically changed just because it sucks as long as it does the job good enough. Where “good enough” is defined as the company isn’t going under.

    Bottom line is that whilst everything you say makes perfect sense from a position of logic and reason we don't live in such a world. And in the real world we live in what you want is tools that let you do your job and do it effectivelly when all reason and proportion come falling sloppy dead.

  • 516052 (unregistered)

    Seriously? For gods sake it's been 3 days. Why is that post still being held up?

Leave a comment on “Quite the Event”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article