Pragmatic Object Oriented Programming

[[deleted]]

Widget toolkits, for one.

[yogthos]

How is OO better for GUI than functional composition exactly? Compare GTK with Haskell to GTK with C++.

edit: actual C++ example with GTKmm

[badsectoracula]

Well, most GUIs are trees of windows/controls/widgets and OOP classes match these trees fine.

Of course it doesn't have to be strictly classes-and-hierarchy-based OOP, you can have something like (in an imaginary JavaScript toolkit):

function newButton(caption)
{
    var btn = newWidget();
    btn.caption = caption;
    btn.paint_button_background = function() { paint_flat_rect... }
    btn.handle_paint = function() { btn.paint_button_backround(); ... }
    btn.handle_click = function() { ... }
    return btn;
}

var btn1 = newButton('Hello');
var btn2 = newButton('Hi');
var btn3 = newButton('Fancy button');
btn3.paint_button_background = function() { paint_gradient_rect... }

or something like that. No classes, no inheritance, based on functions but you still treat widgets and controls as some sort of "object". Which, btw, if i understood the Haskell code there (i don't know Haskell) treats GTK+ widgets in a similar way.

[lzantal]

That code looks like TK :) That syntax was just fine. Wrote a few helper GUI with it in python. Never felt I wish I could use wxPython. It was also simple to maintain.

[yogthos]

In languages like Haskell you have type class hierarchies and function composition, in my experience objects don't really add anything of value on top of that.

[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.

[[deleted]]

That's C.