Exactly!

Perhaps even worse, in my experience (though it took quite a while for me to fully understand how these problems were being encouraged by the same practice), the focus on accessor generation and constructors that expose attributes (and for adding other functionality with a focus on decorating accessors with before/after/around wrappers) leads to OO design that is focused on attributes first, inheritance second, and interfaces a very distant third. This leads to designs that scale over time much less well (based on my experience with quite a few concrete such designs over multi-year lifespans).

The correct priority to use when doing OO design is interface first, attributes a distant second, and inheritance not at all.

Your new best practices need to refine your old best practices not thwart them. Don't adopt OO practices that go against the more basic best practice of encapsulation (narrow interfaces, data hiding).

Also, data types are of profound importance if you are stuck programming with interfaces using positional parameters. But they quite suck in many ways if you aren't stuck in that way. But I think I'll skip the long rant on that part of the topic at this time.

I guess…? I’ve never shared the concern for closed, hidden OO mechanics and I might not even understand your distinction between API and native functionality. Seems academic. We do these things inside the class to prevent typo bugs and leave the “API” open and integral for the other classes that might be concerned. Inside out objects and closures (which is how I would have done the queue to begin with) are possible of course. The point of the quote wasn’t that Perl is the best vanilla OO (the Ruby example is nicer than the most simplistic/direct/synonymous Perl recipes) it was: roles, mixins, coercions, traits, class methods, dispatch, lazy creation, setter/getter/clearer/predicate/builder shorcuts, typing, after, before, around, overriding, non-overriding additions, resolution order, contract style requires, MOP, on the fly generation, etc. :P

By exposing the 'items' attribute via a method, you are telling users of the class that they can use it like this:

6:06% reply -I .
0> use fQ_moonimal;
1> my $q = fQ_moonimal->new(size => 3);
$res[0] = bless( {
         'items' => [],
         'size' => 3
       }, 'fQ_moonimal' )

2> $q->push(2);
$res[1] = ''

3> $q->push(3);
$res[2] = ''

4> $q->push(5);
$res[3] = ''

5> $q
$res[4] = bless( {
         'items' => [
                      2,
                      3,
                      5
                    ],
         'size' => 3
       }, 'fQ_moonimal' )

6> push @{ $q->items }, 7, 11, 13;
$res[5] = 6

7> $q
$res[6] = bless( {
         'items' => [
                      2,
                      3,
                      5,
                      7,
                      11,
                      13
                    ],
         'size' => 3
       }, 'fQ_moonimal' )

8>
[download]

So this version of the queue is not really fixed size. Encapsulation is one of the main motivations for doing OOP in the first place, and giving it up to get feature $X doesn't amount to superior OOP.