[thaumasiotes]

> Whether or not that's the correct decision, it's not an inconceivable design.

I'm having trouble with the part of the design where we recognize that a file is selected (such that pressing <enter> causes a file to open), see the <enter> keypress, and then fire an event saying "open any file, whichever one you feel like" as opposed to "open this file right here, the one we can see is selected".

If, as you maintain, the keystrokes are processed in order, then at the time <enter> is processed, we specifically take notice of which file is selected. (Because, as I said above, we only know that <enter> should open a file at all because we see that a file is selected.) We fire the file-opening event after that. This isn't a mistake we can make by accident; we'd have to be making it on purpose.

I can see where the assumption that the keystrokes are being reordered comes from; it's much less insane than what you're proposing.

[ivanbakel]

Because the event says "open the currently selected file", not "open this file because it is the selected one". If the event is processed asynchronously w.r.t. other events which can modify the selection, you can get buggy behaviour.

I don't find such a design that surprising. If you like simplicity, you would be tempted to go for it, because it doesn't involve duplicating data (namely, the selected filepath) between the main GUI state and the event handler for opening the selected file. If you're writing in a memory-managing language like C, it's even more tempting - by not copying data, you don't risk forgetting to free it later.

[polynomial]

This is a great example of where OOP and FP necessarily part ways.

[FridgeSeal]

That’s a cool idea, how so?

[polynomial]

I'm sure there are far more qualified hn users than I to elaborate, but basically you wouldn't have a dependency on an mutable object. Rather, the object would have to be directly passed to a function.

Having said that, I meant it more generally in the sense of their respective architecture design paradigms than details of a particular implementation.