[WalterBright]

There is one advantage to doing OOP in C. Once you figure it out, the mystery of how OOP works all falls away. Frankly, I didn't understand how OOP worked before doing that. None of the tutorials explained what was going on under the hood.

As an engineer, I'm never comfortable using something when I don't know how it works.

[mst]

While it's hardly a complete object system, perl's bless() operator associating a package name with a data structure, where the package is (for bless()'s purposes at least) basically just a global hash mapping method names to subroutines, was pretty much how I first got my brain around the concept.

I wish more "introduction to OO" things would start by demonstrating a dispatch table and then showing how the vtable concept maps onto that, I suspect it would make things significantly clearer to a bunch of people as they learn.

[heresie-dabord]

> it's hardly a complete object system

While other programming languages became mired in OOP dispute, opinion-battles, and all the ensuing problems[1], Perl 5's built-in OO is easy to learn and understand and makes the difficult things simple. It has been stable and effective for decades.

OO is just a pattern; it can be useful or misused, some aspects are more useful than others. But the defining goalposts are moved all the time. They tend to follow the hype machine.

[1] Members of the Perl community know that OO discussions have become harsh there too.

[mst]

Yeah, I might know a little bit about that, but I was focusing on how bless() helped me initially learn how OO worked at all. (I was after all one of the first power users of Moose, am the original author of Moo and Role::Tiny, and (re)wrote several chunks of the Mojo::Base OO system at various points as well ;)

I'm pretty glad we've mostly standardised on the M* style these days, and Object::Pad (the cpan module that will likely eventually become the template for core OO) is still pretty familiar to users of that as well.

(the days before M* style became the default were ... "fun" ... though at least it meant we got native C3 MRO support added to the perl5 VM to support my decision to use a C3 based component model when I wrote DBIx::Class)