4 ms·

Thinking in terms of messages passing makes you think of the objects in a proper way. Objects just aren't structs with methods on top: you can create lots of t

• _delirium 16y ago
  > Objects just aren't structs with methods on top This view is probably prevalent because C++ more or less does (and did even more in its early days) promote objects as structs with methods and some other fanciness on top, and C++ was probably the first really widespread OO language.
  • vidarh 16y ago
    In fact, in C++ structs and classes are the same thing, only struct declarations starts with public visibility by default and class declarations starts with private visibility by default. That's their only difference in C++. And so instances of structs and instances of classes are the same thing in C++ too. You will even sometimes see member functions defined on structs.
  • _delirium 16y ago
    Replying to myself: an interesting aspect, I think, is that this isn't solely a failing of C++ (though C++ has plenty wrong with it). This model of structs-with-methods had already started appearing in C, in the form of APIs built around sets of functions that all operated on the same struct, which was passed as a void* as the first parameter of all the functions (void* for encapsulation purposes); see the pthreads API, for example. So in some ways it's also a consistent, and even sort of naturally arising, model of OO, sort of an organic development out of structured programming, where structs and associated functions serve a main role in the structuring. It's of course a quite different notion of OO from Kay's message-passing, so maybe should have a different name, if it were an ideal world?
• jules 16y ago
  Multiple or predicate dispatch object systems take the view that objects are structs without methods in them. Methods are just open conditionals: by defining a new method implementation you add a clause to the conditional. e.g. type Animal type Lion < Animal type Elephant < Animal type Giraffe < Animal method encounter(Animal, Animal) def encounter(Lion a, Giraffe b): // eat it def encounter(Lion a, Lion b): // fight Is equivalent to: type Animal type Lion < Animal type Elephant < Animal type Giraffe < Animal def encounter(Animal a, Animal b): if(a is Lion && b is Giraffe): // eat it else if(a is Lion && b is Lion): // fight else: raise NoApplicableMethodError Languages with predicate dispatch usually allow you to define your own predicate classes: def Prime(n): // primality testing algorithm here def Foo(Prime n): ... Or: type Rectangle height width def Square(Rectangle r): height(r) == width(r) def Something(Square x): ... def Something(Rectangle x): ... And they allow you to add predicates to methods themselves: def encounter(Lion a, Giraffe b) when isHungry(a): eat def encounter(Lion a, Giraffe b) when !isHungry(a): walk away This is much more powerful and simpler than message passing, IMO. It's closely related to pattern matching in languages like Haskell, but that's usually not allowed to span multiple modules or files. And algebraic data types are closed, making it much less useful.
  • eru 16y ago
    Yes. There's also the possibilities to have open data types in Haskell. Also type classes, and being able to add instances for any type are closely related to your examples.
    • jules 16y ago
      That's interesting. I've read a paper about it, but I don't remember exactly. Is it implemented in GHC? Type classes are more powerful in some ways, but much less powerful in other ways. There is some overlap, but type classes dispatch only on the compile time type whereas this dispatches on run time predicates.
      • eru 16y ago
• hubb 16y ago
  what is the proper way of thinking of objects that message passing yields (genuinely curious)?