On Thu, 4 Aug 2016 12:10:17 -1000 Joel Roth <[email protected]> wrote:
> What do you mean by "imperative" that contrasts with > something that smalltalk has/does? > > ISTC the original traits paper is in reference to SmallTalk. > > I can't speak to C++ or Java. So when I talk about OO, I'm > speaking through the lens of mainly perl where I commonly > use OO. > To subclass seems so easy and natural way to deal > with situations that would otherwise require > conditionals. The kinds of things that eliminate conditionals can also be done by C structs, Perl hashs, Python dicts, etc. You could, if you wanted to, even pin function references to a struct, hash or dict to avoid OOP. I don't usually do that: I use OOP in when different functions are used for different situations, but you could. > > Something like $this_track->bus->dump or $this_track.bus.dump > seems clearer idiom than bus_dump(bus_of($this_track)). Maybe. The difference is kind of syntactic sugar and isn't HUGELY important though. > That and subclassing really make it for me. > > Anyway, my hat is off to you if you can get by with other > ways of working. I sometimes go OOP, and sometimes not. And some of my programs are basically structured programming with some objects thrown in. I think one would need to be nuts not to represent a data store as an object. Having an application as part of a window object --- not a fan. We're not that far apart here. What I originally said was: =============================================================== Then there's OOP. My opinion: OOP didn't achieve our expectations for it, it's often misused, it's vastly misunderstood. =============================================================== Expectations: 1990 - 2005 OOP was expected to be the savior. It would cure all our coding ills. Coding factories. Less errors. Useable by less skilled programmers. For the most part, that never happened. Expectations (again): They said OOP must be all or nothing. Smalltalk good, Perl bad. No fair using structured code where it works best, and objects where they work best. Nope, if you're not 100% OOP, you're just a hack. LOL, Java required the main routine to be in a class: I'm forever seeing main classes that obviously are kludges for (disallowed) structured code. Often misused: How many hundreds of times have you seen somebody willy-nilly substitute a "has-a" relationship for an "is-a" relationship, and vice versa. How often have you seen completely unrelated things thrown into a class because "it seemed like a good idea at the time"? How many times have you seen code tracing turn into a volleyball game, where logic bounces repeatedly between three or four objects? How many classes have you seen whose sole purpose was to take data from one object to another? Dbus, anyone? Misunderstood: In 1990-2005, ask ten experts what OOP is, and you got ten different answers. NOBODY understood it, but they all thought they did. Structured programming, which immediately preceded OOP, had an agreed on definition and came with an iron-clad program building methodology: functional decomposition. As far as I know, no program building methodology for OOP ever emerged from the cauldron of DIY, one-offs, and expert book author pablum. Hey, I use OOP. Anything in my programs that resembles an entity becomes an object. If objects contain objects like a classroom contains students, I have no problem putting objects in other objects. If I have several objects that are almost the same but have differences, I have no problem using inheritance. I'm just saying some people endorse it as the only valid paradigm, and when they try to use it as their only paradigm, their code sucks. SteveT Steve Litt August 2016 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
