3 ms·

> So in Pascal the best you can do is write a switch function for each function pointer type (signature) and use an enumerated type or equivalent to dispatch ca

> So in Pascal the best you can do is write a switch function for each function pointer type (signature) and use an enumerated type or equivalent to dispatch calls. Yeah, you would have to spell it out and you couldn't do compile-time optimizations, but you could get all the dynamic flexibility you need? Really, what I was saying above is just that if your problem is easier to describe as a bunch of interacting "objects" (like a game or a factory sim) then use OOP, but if it's easier to describe as a set of functions and data structures then don't use OOP. :-)

kragen 7y ago
Well, sort of; I mean clearly Pascal is a Turing-complete programming language, so it provides you all the flexibility you need. But if you write a switch function for each function pointer type, it means that local changes in an OO language, or in C, map to global changes in the Pascal translation of it, so I'd argue that the OO language, or C, is more expressive in a fundamentally meaningful way. (Actually existing implementations of Pascal usually added a function pointer type of some kind, but I'm talking about the language standard.) I think the crucial question is whether the objects have different behavior. If all the objects implement a particular operation in the same way, or in one of two or three ways, there's no advantage to OOP. If their behavior varies in an open, expandable way — like, you might have an arbitrarily large number of monsters whose movement strategy varies arbitrarily — then OOP, or function pointers, can be helpful. If their behavior needs to vary in orthogonal and arbitrarily combinable ways, OOP may not be expressive enough, and maybe you should look at an entity-component-system architecture.
- carapace 7y ago
  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.

kragen 7y ago

Well, sort of; I mean clearly Pascal is a Turing-complete programming language, so it provides you all the flexibility you need. But if you write a switch function for each function pointer type, it means that local changes in an OO language, or in C, map to global changes in the Pascal translation of it, so I'd argue that the OO language, or C, is more expressive in a fundamentally meaningful way. (Actually existing implementations of Pascal usually added a function pointer type of some kind, but I'm talking about the language standard.) I think the crucial question is whether the objects have different behavior. If all the objects implement a particular operation in the same way, or in one of two or three ways, there's no advantage to OOP. If their behavior varies in an open, expandable way — like, you might have an arbitrarily large number of monsters whose movement strategy varies arbitrarily — then OOP, or function pointers, can be helpful. If their behavior needs to vary in orthogonal and arbitrarily combinable ways, OOP may not be expressive enough, and maybe you should look at an entity-component-system architecture.

carapace 7y ago
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.