This is a comment on a topic that came up in #278 at about 18m50s: "...having something where events can happen, versus having something where events are part of the environment..."
I understood this point immediately, but others (Tor, ...) on the podcast obviously didn't. When I first began developing with Swing, I found the whole listener registration business rather surprising. - I found it surprising that I had to go explicitly register listener objects with every event and object combination I was interested in listening to. - I found memory usage problems that came from forgetting to unregister listeners and then having them hang around in memory forever to be stupid oversight in the design of the whole idea. Why? Because I had previously worked with systems that worked very differently, and Swing felt like a huge step back at least with regards to its event model. # Oberon Before getting a job in the Real World, I had been hacking on Wirth and Gutknecht's [Oberon][1] System 3. Oberon was Object Oriented, after a fashion which worked like this: [1]: http://en.wikipedia.org/wiki/Oberon_%28operating_system%29 - Every window ("Frame") was an object, which meant: - it was (pointer to) a record (a struct) containing state - part of that state was a single procedure pointer Handle(self: Frame; VAR msg: Message) "Sending a message" was understood very literally. Messages were instances of some extension of a base record type. You filled them out and sent them off at which point they were *broadcast to all viewers in the view hierarchy*, which reacted to the ones they were interested in possibly by forwarding them on to their children (contained widgets) and ignored the rest. There was no registration and there was no dangling objects due to forgetting to unregister listeners. Every component was was in the visual hierarchy and was thus in on all message broadcasts. You didn't have to do anything, except react to messages that interested you when they came. Closing a window automatically removed it from the view hiearchy. System 3 extended the classic Oberon system by extending this concept to non-visual ("model") components and providing a rich set of GUI widgets ("Gadgets"). Oh yea, and a compound document model ("Libraries"). In many ways, it was an astonishingly innovative system. In other ways it was just as astonishingly minimalistic. That's Niklaus Wirth for you. - Messaging was ubiquitous. - You didn't have to do anything special to announce your interest in messages. - Since messages were data, not tarted up procedure calls, generic broadcasting and forwarding was possible. - Your applications could define their own message types and use a system wide broadcast to communicate between model and view. Generally, one module would implement the Model and define some kind of UpdateMessage. Another module would impelement a view. Each view instance would inspect all UpdateMessages that passed by to see if they pretained to the particular model instance it was displaying. # HyperCard One of my early programming experiences was with HyperCard. HyperCard was also Object Oriented after a fashion. In hypercard there was a fixed message delegation hiearchy, and indeed a fixed set of objects. You couldn't defined your own classes, but you could add "handlers" (methods) to existing objects. - A stack consisted of 1 or more backgrounds and 1 or more cards. - Every card had one "background". - (Every background was used by at least one card) - Every card/background contained zero or more GUI controls. You can think of the "card" as a screen-full, containing graphics and GUI elements. The background allowed you to capture the common elements that were shared by one or more cards. Each Stack/Background/Card/Control had an associated script. For example, a button might contain the following handler in its script: on mouseUp answer "You clicked the mouse!" end mouseUp A click and relase on the button would produce a dialog box displaying the message. If the button has no such handler, a mouseUp event will be forwarded on to the card, the background, the stack and finally hypercard itself for hadling. "on mouseUp" reacts to the mouseUp message, which is built in to HyperCard, but you can define your won handlers with our own names. Because of the message hierarchy, you could define "utility methods" as handlers (or functions) in your Stack and call them from any GUI element, card or background handler. Thus in hypercard every "method call" was actually just an event that searched up the chain of reponsibility for a suitable handler. Every "method" was just a hanlder for one particular kind of event. Food for Thought // Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
