Looking from the code in Messenger.send, it appears that the debug watches are setup to print out debug info on any event that contains the name used in the debug watch.
The code is obviously explicitly written to do this (it’d be much easier just to search for exact matches), so I’m wondering what the recommended/intended use is.
The main use I can see is implementing “namespaces” in the code, which would allow you to have events like “KB.enter” and “Mouse.LeftButton” or such, and then you can setup a watch for “KB” and get any keyboard event.
But, the rest of the code isn’t setup to work with this (or atleast not to take advantage of any options it presents like accepting all keyboard events automatically), and from what I can tell of the various event names that I’ve seen, it doesnt’ appear that any namespaces are being used.
Having the watcher code setup like this also has the effect that, even if you didn’t intend any sort of namespace setup, an event like “AvatarMovementFrozen” would trigger a watch on “AvatarMove”. Obviously this can be avoided with better naming of events, but the effect would still be a bit confusing if you didn’t know the implementation of the code.
I think I may be missing the purpose of the code, so perhaps someone could enlighten me?
yes, it looks like watching is keyword based. It doesn't seem like that much of an issue, as it is for debugging purposes only. Also, if a class is using many different events with similar names, being able to watch on all of them with one line seems useful.
Anywho, the end result is that since its debugging code, and since the worst case is explicit info on a function you don't want, I doubt anyone ever considered it much beyond that.
yes, it looks like watching is keyword based. It doesn't seem like that much of an issue, as it is for debugging purposes only. Also, if a class is using many different events with similar names, being able to watch on all of them with one line seems useful.
Anywho, the end result is that since its debugging code, and since the worst case is explicit info on a function you don't want, I doubt anyone ever considered it much beyond that.
Aye, I don’t think there’s any problem, I just wasn’t sure if I was misinterpreting it or not.
I am a bit more confusd now, because the find() method uses the same technique, and thus could return you an event that is not at all the event you were searching for. I can understand being able to watch multiple events with a single keyword, but I think that when you are attempting to find a specific event, the method should only return that event. Perhaps a findSimilar() would be a better name for the current technique.