in reply to Re^7: The future of Perl?
in thread The future of Perl?

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

Replies are listed 'Best First'.
Re^9: The future of Perl?
by Arunbear (Prior) on Dec 16, 2014 at 18:25 UTC
    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>
    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.