3 ms·

That's basically what the Oberon OS messaging system did, it was a little clunky but it worked. The Gadgets widgets system is still my favorite after all these

That's basically what the Oberon OS messaging system did, it was a little clunky but it worked. The Gadgets widgets system is still my favorite after all these years. It was like OLE but good. I agree, if your code doesn't need objects, there's no advantage to OOP. and ECS is like extra-OOP. :-) (I replied to your reply in the other thread, BTW.)

kragen 7y ago
At least the version of the Oberon OS described in the book used the built-in Oberon support for function pointers for dynamic dispatch; were you looking at an earlier or a later version than the one in the book?
- carapace 7y ago
  I'm talking about the Viewer message system. There's a "coarse-grained view" on pg. 46 of https://inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf https://inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.p...
  - kragen 7y ago
    Right, that's what I was talking about too; although the version of the book I read was the 1992 edition, this part of the system hasn't changed. It works by using the Oberon language's support for embedding function pointers ("procedure variables") within records, which is precisely what was prohibited in Pascal. You give different windows ("viewers") different behavior by giving them different Handle procedures ("WndProcs", you might say, or "overridden methods") so that, when the system ("controller") sends a message to the viewer, it can behave in a dynamically determined way.
    - carapace 7y ago
      Yes, the Handle procedures are associated with their objects by means of function pointers (for e.g. C++-style OOP), but also inside themselves they implement big ol' IF,THEN,ELSE chains to do (Smalltalk/Actor-style OOP) messaging handling.
      - kragen 7y ago
        Oh, I see what you mean — instead of having a function pointer per message type, say, stored in a vtable, the handlers for each message type are dispatched by a function, which can do things like delegation (Smalltalk doesNotUnderstand:). Piumarta's "COLA" approach is a sort of hybrid, where you dispatch with a function, but the dispatch function returns a function pointer you can then cache at the call site. What I was saying about Pascal is that instead you'd have to have a function that dispatched on the receiver type, not the message type. I thought you were saying that the Oberon OS was doing that, even though the Oberon language supported function pointers.
        carapace 7y ago
        Yeah, cheers! ^_^ (It took me years to notice that.)

kragen 7y ago

At least the version of the Oberon OS described in the book used the built-in Oberon support for function pointers for dynamic dispatch; were you looking at an earlier or a later version than the one in the book?

carapace 7y ago
I'm talking about the Viewer message system. There's a "coarse-grained view" on pg. 46 of https://inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf https://inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.p...
- kragen 7y ago
  Right, that's what I was talking about too; although the version of the book I read was the 1992 edition, this part of the system hasn't changed. It works by using the Oberon language's support for embedding function pointers ("procedure variables") within records, which is precisely what was prohibited in Pascal. You give different windows ("viewers") different behavior by giving them different Handle procedures ("WndProcs", you might say, or "overridden methods") so that, when the system ("controller") sends a message to the viewer, it can behave in a dynamically determined way.
  - carapace 7y ago
    Yes, the Handle procedures are associated with their objects by means of function pointers (for e.g. C++-style OOP), but also inside themselves they implement big ol' IF,THEN,ELSE chains to do (Smalltalk/Actor-style OOP) messaging handling.
    - kragen 7y ago
      Oh, I see what you mean — instead of having a function pointer per message type, say, stored in a vtable, the handlers for each message type are dispatched by a function, which can do things like delegation (Smalltalk doesNotUnderstand:). Piumarta's "COLA" approach is a sort of hybrid, where you dispatch with a function, but the dispatch function returns a function pointer you can then cache at the call site. What I was saying about Pascal is that instead you'd have to have a function that dispatched on the receiver type, not the message type. I thought you were saying that the Oberon OS was doing that, even though the Oberon language supported function pointers.
      - carapace 7y ago
        Yeah, cheers! ^_^ (It took me years to notice that.)