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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

--
Joel Roth