On Thu, Aug 04, 2016 at 09:11:22AM +0200, Enrico Weigelt, metux IT consult wrote: > On 04.08.2016 08:43, Joel Roth wrote: > > > In which language? Whose expectations? > > Probably you never used OO much, or had problems > > that OO is well suited to solving. > > I'd guess, he's referring to the imperative OOP, like eg. C++, > Java, etc are doing it (smalltalk etc are quite different) - at > least that's what I'm referring to.
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. Something like $this_track->bus->dump or $this_track.bus.dump seems clearer idiom than bus_dump(bus_of($this_track)). 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. > > To say that the ability to apply a method to an > > object offers nothing valuable over a simple subroutine call > > is missing a lot I think. > > Well, the actual benefit comes with inheritance. But that also > can be easily done w/ stupid call vectors (okay, a little bit > more typing when having to write constructors on your own). > > Generic types (or templates), of course, are a different area. > But when I really need such things, I'd probably go for > functional languages anyways. > > OO has made it possible for me to structure and refactor a > > medium-size codebase that was procedural before. The ideas > > of instantiating and destroying objects are easily made > > explicit in OO. Statements like my $object = $class->new() > > and $object->DESTROY are quite expressive. > > What's the big difference to something like that ? > > $obj = class_new() and class_destroy($obj) > > If you're already here, you can also decide whether you wanna > let the constructor do the allocation or do it on your own > (in case the caller knows the size), so the caller can decide > where to actually put it: > > class_init(&inst) > class_fini(&inst) > > That's actually the approach done in many C-projects, eg. the > Linux Kernel or Cairo. > > > More recently, an > > OO concept called traits (or roles) has made it possible for > > me to reduce classes into smaller blocks of code. Traits can > > be used to avoid multiple inheritance. > > hmm, I actually never had a real usecase for that yet ... > > > Enrico Weigelt, metux IT consult wrote: > >> ACK. I really wonder what [OO is] actually useful for ... > > > > Well, you mention composition as an alternative to > > inheritance, but isn't that still classes, methods and objects? > > Well, depends on whether you call an ADT (IOW: struct w/ some > functions operating on them) an class ... in that case, you'd > have to call the Linux Kernel OOP'ed. > > > --mtx > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng