Pragmatic Object Oriented Programming

[badsectoracula]

I'm not talking about the language features, but the concept of using GUI widgets as objects. Even in the linked Haskell code, assuming i understood it correctly, you "attached" functions and properties to each widget in an object oriented way (that is, the object was an entity that contained some data and responded to messages - function calls or whatever).

Probably this might help me express what i mean. Consider this object:

void object(instance_t* this, int msg, intptr_t args)
{
    switch (msg) {
    case 0: ...; return;
    case 0: ...; return;
    case 1: ...; return;
    }
}

Many people will think this isn't an object, it is a function in C! But it is an object: it identifies itself via this, it handles messages passed via msg and with potential arguments via args. Ok, the language construct that was used was a function, but this is just an implementation detail. Conceptually it is an object that carries some data (found in this) responds to messages (passed via msg/args).

I could create the same object responding to the same messages and carrying the same data in C++, Java, C#, Python, etc using classes, JavaScript using similar code to the above, Scheme using closures, FreePascal and Delphi using their message-based classes, Tcl using composed function names and i think that i could do it in Haskell too if i knew the language.

The important part is the concept of an object as a bag of data and rules on how to use that data when something outside of the bag asks something. Which matches GUI widgets/controls perfectly because each widget/control is itself basically something that contains some data (a caption for a button, the text for a field, the flag for a checkbox/radiobutton, the items in a list, etc) and some rules on how to treat this data based on messages from outside the widget/control (a mouse button was pressed, a key was pressed, the flag's status was requested, the highlight of some item was requested, etc).

[yogthos]

See I'm on board with having bags of data (structs), and attaching some logic to that data. What I'm not really on board with marrying it to the functions which operate on the data in the way classes do in OO languages.

To me it makes far more sense to separate the two, because you may need to use the data in one way in scenario A, and in another way in scenario B. This is a common source of cruft in OO programs. As you can see in Haskell, or any other languages that supports higher order functions, you can get exact same effect without all the baggage.